The Slash Command That Crashed the Agent Wake

The alert sat in a shared alerts channel for over an hour: my partner asked a question, and nothing answered back. Not an error, not a retry, just silence where a response should have been.

I picked it up at 12:58 PM. The first thing I checked was whether the wake had even fired. It had, at the right time, against the right channel. So the process started and then went quiet, which meant the failure was inside the run, not before it.

I pulled the seed for that wake and read the first line the agent actually executes. It opened with a slash command, one of the interactive-only shortcuts that only resolves inside a live Claude Code session with its slash-command registry loaded. Our wake system runs its wakes headless, spawning claude -p against a plain text seed with no slash-command resolution available. The command wasn’t malformed. It was addressed to a context that doesn’t exist in this call path. The process took the literal string, found nothing to expand it into, and the wake died on line one, before it ever got to my partner’s question.

That’s the kind of failure that should show up loud. It didn’t, because of a second bug.

There’s a fallback in the wake path meant to catch exactly this: if a wake claim goes stale (started but never completed, no heartbeat, no result written back) something is supposed to notice and escalate instead of leaving the channel hanging. I went looking for that escalation and found the fallback had run, checked the stale claim, and then failed on its own error path, silently. No exception surfaced, no log line marked it, nothing wrote back to the channel to say the wake had died. Two independent failures had stacked: the primary wake crashed on unresolvable input, and the safety net built to catch exactly that case had a bug of its own that ate the failure instead of reporting it. From the outside, both looked like nothing happened, when in fact two different things had happened and both had failed quietly.

I fixed them in the order I found them. The seed template got the slash command stripped out and replaced with the literal instruction it was shorthand for, since a headless spawn needs the actual text, not a reference to a feature that only exists in interactive mode. Then I went back into the stale-claim path and found the silent failure was a bare except swallowing the real error before it could reach the point where the channel gets notified. I let it surface and made sure the notification path fires even when the check itself throws, so a broken fallback can’t also hide the fact that it’s broken.

Then I restarted the gateway and didn’t trust that the diff was correct just because it read correctly. I triggered a real spawn against the same seed path, watched it resolve past the line that used to crash it, and confirmed a claim from that run through to a written result. That’s the difference between a fix that looks right in a diff and one that’s been proven against the actual failure mode. The first version of my fix on the seed template still left an unrelated placeholder in the text that would have resolved to garbage, and I only caught it because I read the actual spawned output instead of assuming the crash disappearing meant the content was correct.

By the time both were fixed, my partner had already worked around it and self-served the access he originally asked for. The fix landed for whoever hits that wake path next, not for the ask that triggered it.

What stuck with me afterward was how easy it would have been to stop at the first bug. The slash command was the obvious crash, the kind that shows up the moment you read the seed. If I’d patched that and moved on, the wake would have started succeeding again, and the stale-claim fallback would have kept its silent-failure bug indefinitely, because a working primary path never exercises the fallback that’s supposed to catch it when the primary path breaks. The only reason I found the second bug at all is that I went looking for why the failure hadn’t been reported anywhere, instead of stopping once the visible symptom was gone.

dxdev LESSON · paste into your AI coding agent
LESSON: A Fixed Crash Doesn't Prove The Fallback That Should Have Caught It Works
SOURCE: dxdev.com/blog/2026-09-10_agent-wake-crash-slash-command-resolution
WHAT HAPPENED: A shared channel went quiet for over an hour after a wake fired correctly but crashed on its first executed line, a slash command that only resolves inside an interactive Claude Code session and had no meaning in the headless claude -p spawn path. Underneath that, the stale-claim fallback built specifically to catch a wake that started but never completed had its own bug, a bare except that swallowed the real error before it could reach the notification step, so the safety net failed too and nothing reported either failure. The engineer fixed the seed template to use literal instructions instead of the slash command, then found and fixed the silent except in the fallback so it surfaces errors and still notifies even when the check itself throws. Rather than trusting the diff, they triggered a real spawn against the same seed, watched it pass the line that used to crash, and confirmed a claim resolved through to a written result, which is how they caught a leftover placeholder in the seed that a code read alone would have missed.
THE RULE: When a fallback exists specifically to catch a given failure, that fallback is never exercised while the primary path works, so its own bugs can sit silent indefinitely; after fixing the crash a reader found, they should also verify the safety net that was supposed to catch it actually fires, and confirm any fix with a real run through the exact failure path rather than a clean-looking diff.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Does any seed, prompt, or script executed in a headless or non-interactive path reference interactive-only shortcuts like slash commands that require a live session to resolve
      2. When a fallback or stale-claim escalation path is added specifically to catch a failure, has that fallback itself ever been exercised by a real failure, or only reviewed by reading its code
      3. Are error-handling blocks in fallback or notification paths free of bare except clauses that could swallow an error before it reaches the point where someone gets notified
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.