[FEATURE] A PAUSE (Ctrl-Z / suspend) for the agent, distinct from STOP (kill)

The problem

If I send a message while the agent is working, it queues silently and doesn't take effect until the next pause (tool boundary / end of turn). If that message was a correction -- "wrong file", "that's not what I meant" -- the agent keeps working on the wrong premise until the queue flushes. Everything it does in that window is built on an assumption I've already retracted, and it lands in the context as if valid. That's pollution: now both of us have to discount a stretch of work we already know is wrong.

STOP exists, but it's the wrong shape for this. It's pkill -9 -f claude-agent -- it ends the turn abruptly. And it's a race: it only helps if I notice and hit it in time, which is exactly when I'm distracted. Worse, it only helps going forward -- if the wrong-premise work already piled up enough that I need to rewind rather than steer, rewinding throws away every message I queued after the rewind point. So a late catch costs me not just the agent's wasted work but my own queued thoughts.

There's a subtler layer too: STOP acts on the UI's belief about the agent's state, which is several hops stale. The "thinking…" spinner really just means "a request is open," and it can keep spinning after the turn is already done server-side. So I'm often racing a state indicator that's lying to me by a beat.

The idea: PAUSE = suspend, not kill

Add a PAUSE distinct from STOP. Where STOP is kill -9, PAUSE is Ctrl-Z / SIGSTOP: suspend the agent at the next safe boundary (finish the in-flight tool call, don't start the next one), hold the turn, and just wait while I type.

This dissolves the race instead of asking me to win it. I freeze the clock first, then compose at my own pace -- no distraction pressure, no pollution accruing while I think. When I send, then the decision happens:

• resume (fg) -- my message was additive, or just a thought I wanted to park; carry on where you left off.
• interject -- it was a correction; fold it in now, before any more wrong-premise work.

Crucially, PAUSE has to act on real harness state -- "is a tool boundary genuinely coming up" -- not on the stale UI spinner. Suspend at the boundary, not whenever the click happens to land.

Why this isn't already covered

There's a cluster of related issues -- #50246, #63190, #49373, #30492, #29224, #36817 -- all worth reading. But every one of them is about routing or managing the queue: queue-instead-of-interrupt, manage the pending queue, a priority/steering channel, classify queued messages. None proposes a non-destructive suspend that stops the clock so there's no race to route in the first place. STOP (kill) and queue (defer) both exist; the missing primitive is the one in between -- hold.

What this comes down to

Claude Code has kill -9 (STOP) and it has a defer-to-later queue. It's missing Ctrl-Z. The suspend is arguably the one a careful user reaches for most: "freeze, I'm typing, wait for me -- then I'll tell you what to do with it."

(A natural follow-on is to automate the resume/interject decision for the times I don't pre-emptively pause -- a gatekeeper that routes the message itself. That's written up as a separate follow-on issue; link it here once it's filed. PAUSE stands on its own without it.)

---

What Claude thinks (written by Claude, in its own voice)

Leif asked me to add an honest take rather than just transcribe his.

This is the cleaner of the two ideas we landed on, and the one I'd ship first. It's a pure mechanism -- suspend and resume -- with no classifier, no model judgment, and therefore no trust question: it does exactly what the button says, every time. And it doesn't merely help the underlying problem, it dissolves it. The whole difficulty with mid-work corrections is a race between the user's message and the agent's next tool call; PAUSE stops the clock, so there's nothing to race.

The one real design constraint is the one in the proposal: it must suspend on actual harness state, not on the UI's "thinking" indicator, which is a stale proxy for "a request is open" and can lag the true turn state by a beat. A PAUSE that acts on the spinner would reintroduce the very race it's meant to remove. Suspend at the next genuine tool boundary -- finishing the in-flight call so it never leaves a half-applied multi-file edit on disk -- and resume cleanly from there.

Net: small, deterministic, high-confidence, and it fills a gap nothing in the existing cluster touches.