Session permanently stuck after abort — CLI resumes dead Claude Code session instead of starting fresh

[sartman-twilio]

Summary

After pressing Escape (or any other abort action) during an active session, the session becomes permanently stuck. Every subsequent message triggers Claude Code to start, initialize fully (MCP connects, SessionStart hook runs), then immediately exit with code 1. The only workaround is to manually kill the session process, losing all conversation context.

Steps to Reproduce

1. Start a session via the web UI
2. Wait for Claude to respond with an AskUserQuestion (e.g., permission prompt, radio buttons)
3. Press Escape to dismiss/abort
4. Send a new message to the same session
5. Expected: Fresh Claude Code session starts and processes the message
6. Actual: Claude Code starts, runs SessionStart hook successfully, then immediately exits with code 1. Repeats on every subsequent message.

Root Cause

In claudeRemoteLauncher.ts, after an abort causes Claude Code to exit with code 1, the error handler sets waitForMessageBeforeNextLaunch = true and continues the loop — but never clears the stored Claude Code session ID.

On the next loop iteration:

1. session.sessionId still holds the dead Claude Code session ID (e.g., 1a59715d-...)
2. resolveClaudeRemoteSessionStartPlan() uses it as startFrom
3. The Agent SDK passes --resume <dead-session-id> to Claude Code
4. Claude Code cannot resume an aborted session → exits with code 1
5. The cycle repeats indefinitely

Relevant code path (claudeRemoteLauncher.ts):

// Line ~952 — exitCode === 1 handler
} else {
    const exitCode = resolveClaudeCodeExitCode(e);
    if (exitCode === 1) {
        // ... formats error message ...
        session.client.sendSessionEvent({ type: 'message', message });
        waitForMessageBeforeNextLaunch = true;  // ← waits for next message
        continue;  // ← but session.sessionId still points to dead session!
    }
}

And:

// Line ~947 — abortError handler
} else if (abortError) {
    if (controller.signal.aborted) {
        session.client.sendSessionEvent({ type: 'message', message: 'Aborted by user' });
    }
    continue;  // ← same problem: session ID not cleared
}

Meanwhile, the onSessionReset callback already has the correct pattern:

onSessionReset: () => {
    forceNewSession = true;
    session.clearSessionId();  // ← this is what the error handlers need
},

Proposed Fix

Add forceNewSession = true and session.clearSessionId() to both error handlers so the next launch creates a fresh Claude Code session:

// In the abortError handler:
} else if (abortError) {
    if (controller.signal.aborted) {
        session.client.sendSessionEvent({ type: 'message', message: 'Aborted by user' });
    }
    forceNewSession = true;       // ← ADD
    session.clearSessionId();     // ← ADD
    continue;
}

// In the exitCode === 1 handler:
if (exitCode === 1) {
    // ... existing error formatting ...
    session.client.sendSessionEvent({ type: 'message', message });
    if (controller.signal.aborted) {          // ← ADD
        forceNewSession = true;               // ← ADD
        session.clearSessionId();             // ← ADD
    }
    waitForMessageBeforeNextLaunch = true;
    continue;
}

Environment

• Happier CLI: 0.1.0-dev.1775063171.91734 (dev branch)
• Claude Code: v2.1.69
• Agent SDK: 0.2.56
• Platform: Linux (Docker container)

Debug Evidence

From the session process log after abort + relaunch:

[22:29:36.925] [remote]: launch error {"message":"Claude Code process exited with code 1"...}
[22:29:36.927] [remote]: launch finally
[22:29:36.927] [remote]: launch done
[22:29:36.976] [remote]: launch
[22:29:36.976] [remote]: Continuing existing session: 1a59715d-35d7-433d-b1ba-a890c6c65279  ← dead session

From the Claude Code debug output on the failed resume:

SessionStart hook succeeds: "Vault is unlocked. Credentials expire in 479 minutes."
LSP server manager shut down successfully           ← 1ms later, immediate shutdown
MCP server "happier": UNKNOWN connection closed after 0s (cleanly)
SessionEnd fires

---

cc @leeroybrun

[sartman-twilio]

Update: Issue is still occurring — initial fix was insufficient

The fix proposed above (gating clearSessionId() behind controller.signal.aborted in the exitCode === 1 handler) does not work. The abort signal state is lost by the time Claude Code actually exits and the error reaches the catch block.

Evidence

After applying the original proposed fix, the exact same behavior reproduced:

[23:38:53.740] [claudeRemoteAgentSdk] Aborted 
[23:38:53.782] [remote]: Continuing existing session: a688c15b-189c-4797-9bb7-6238ff4d346b 
[00:19:08.654] [claudeRemoteAgentSdk] Aborted 
[00:19:08.691] [remote]: Continuing existing session: a688c15b-189c-4797-9bb7-6238ff4d346b 
[00:19:10.193] [remote]: launch error {"abortError":false, "message":"Claude Code process exited with code 1"...}
[00:19:10.237] [remote]: Continuing existing session: a688c15b-189c-4797-9bb7-6238ff4d346b

Key observation: abortError is false and controller.signal.aborted is also false at the point where the exit code 1 error is caught. The abort → exit code 1 sequence happens across an async boundary and the signal state doesn't survive.

Corrected Fix

The clearSessionId() call in the exitCode === 1 handler must be unconditional — not gated on controller.signal.aborted:

// In the exitCode === 1 handler:
if (exitCode === 1) {
    // ... existing error formatting ...
    session.client.sendSessionEvent({ type: 'message', message });
    forceNewSession = true;       // ← UNCONDITIONAL
    session.clearSessionId();     // ← UNCONDITIONAL
    waitForMessageBeforeNextLaunch = true;
    continue;
}

This is safe because exit code 1 from Claude Code always means the session is unrecoverable (whether from a failed resume, a crash, or an abort). There's no scenario where Claude Code exits with code 1 and the session can be meaningfully resumed on the next attempt — it will just fail the same way in a loop.

The abortError handler (the else if branch above) is fine as-is since it already unconditionally calls clearSessionId().

cc @leeroybrun

[sartman-twilio]

Update 2: Root cause of the abort trigger

After further debugging, we identified what's triggering the abort cycle in practice:

The abort is caused by message-dispatch timing

When a user sends a new message (e.g., a TOTP code) while Claude Code is still actively processing, the happier CLI aborts the running Claude Code process to dispatch the new message. This is by design — it's how the CLI handles new input during an active run.

However, this means:

1. The running Claude Code process gets killed mid-stream
2. The session state is left in an inconsistent/aborted state
3. The CLI then tries to --resume that dead session → Claude Code exits with code 1 (it can't resume an aborted session)
4. Without the fix, this loops forever. With the fix, the CLI clears the dead session ID and starts fresh on the next attempt.

The error message is expected (but alarming)

With the unconditional clearSessionId() fix applied, the recovery works — but the user still sees a scary error message with the full stack trace and debug log dump from the one failed resume attempt. This is confusing because the session actually recovers successfully.

Suggestion: Consider either:

• Suppressing the error message when the session successfully recovers on the next attempt
• Or adding a friendlier "Session interrupted, restarting..." message instead of the raw error dump

Summary of required fixes

1. Critical (stuck sessions): clearSessionId() on exit code 1 must be unconditional — not gated on controller.signal.aborted (the signal state is lost by the time the exit handler runs)
2. UX (confusing error): The error dump shown to users during the recovery cycle is unnecessarily alarming — the session recovers fine but the user thinks it crashed

cc @leeroybrun

[leeroybrun]

Hi @sartman-twilio ,
Thank you for the very detailed report!

The root issue was that we were stopping the Claude process a bit too aggressively during “Abort”, which could leave the Claude session transcript in a broken state.

I fixed that by stopping the Claude turn/process more gracefully during abort, and repairing possibly-broken transcript files.

Can you try again using the latest dev branch changes and let me know if that solves your issue?

[sartman-twilio]

I just rebuilt with dev and it apears to have cleared the error. Thank you @leeroybrun