Restart ≠ Resume: why a rotated session stops

What "the composer" is, why an auto-rotated Claude session lands there and does nothing, and why it felt seamless when you were driving a few sessions by hand.

2026-08-28 · agent-ops / infra · confirmed from the live ccswitch source + its full git history, not a theory

Restart is not resume. When ccswitch rotates a capped session onto a healthy account, it kills the process and relaunches it with claude --resume. That reloads the whole conversation — and then stops at an empty composer. No prompt is submitted, so no work happens until someone (a human, or a script) presses Enter.

The three words this hinges on

Composer
The input box at the bottom of a Claude Code session — the ❯ line where a prompt gets typed. An empty composer means the agent is sitting there, alive, waiting for input.
Turn
One round of actual work: a prompt goes in, the agent thinks and acts, then stops. Work only happens during a turn.
"Hitting Enter"
Submitting whatever is in the composer. That is the thing that starts a turn. Text sitting in the composer unsent, or an empty composer, means zero work — the session just waits.

The picture: what happens when a session hits its cap

Today — what ccswitch does

Session hits its 5-hour cap
↓
ccswitch kills the processtmux respawn-pane -k
↓
relaunches itexec claude --resume <sid>
↓
the conversation reloads
(now on a healthy account)
↓
❯ (empty — nothing submitted)
↓
SITS IDLE FOREVER
looks "alive + running", does nothing

The fix — restart and continue

Session hits its 5-hour cap
↓
ccswitch kills the processtmux respawn-pane -k
↓
relaunches itexec claude --resume <sid>
↓
the conversation reloads
(now on a healthy account)
↓
❯ continue  ← auto-typed + Enter
↓
WORK RESUMES
the one missing keystroke

The two paths are identical except for the last step. Everything ccswitch already does is correct — it just stops one keystroke short.

Why it felt seamless before

Your memory is right: five sessions, auto-rotate, you kept working and never noticed. That is exactly what you'd expect — because you were the missing keystroke.

With a handful of sessions that you were actively driving, a restart-to-empty-composer was invisible friction. You were mid-conversation anyway, so you just typed your next message — and that message was the Enter that started the next turn. The rotation swapped the account underneath you and you resumed by typing, so it looked automatic. It never was.

The proof (not another assumption)

This is read straight out of the installed ccswitch, not inferred. The restart is one line, and there is deliberately no keystroke after it:

cmd = f"cd {cwd} && exec claude --resume {session_id}{LAUNCH_FLAGS}" subprocess.run(["tmux", "respawn-pane", "-k", "-t", pane, cmd]) # ...and nothing else. No send-keys, no "continue".

The function's own docstring says it on purpose: "respawn-pane (not send-keys)." And the whole git history confirms it has never injected an Enter — a search for the tmux Enter keystroke (C-m) across every commit returns nothing. So "it worked before" was never the old code auto-continuing. It was a person.

The fix, in one sentence

Killing a session quickly at a threshold is fine — it's already half-built (auto_switch: true, session_threshold: 90). The only missing piece is the auto-continue.

PropFlow Docs