Remote planning session: deferred approval tool splits the turn, session drops out of plan mode ("not in plan mode"), plan is lost with no recovery path

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment

• Client: Claude Code CLI (native installer, v2.1.219–2.1.220 at the time), running on a Linux VPS (Ubuntu, kernel 6.8) inside tmux, accessed over SSH from a laptop via Warp. Connection stable for the whole session.
• Session type: remote planning session — plan refinement running in an ephemeral cloud container, bridged to the local CLI (plan-mode state, approval request, and plan teleport all travel in-band over that bridge).

What happened

1. The remote session finished writing the plan. At that point the plan existed only in the cloud container's filesystem (as the flow intends prior to handoff).
2. The plan-approval tool was deferred: loading it required an extra round-trip, which widened the window between "plan ready" and "approval request sent".
3. Inside that window the turn was interrupted: the tool-load result arrived as a new turn, indicating the in-flight request had been cut. The client was stable (laptop + Warp + tmux, no connectivity loss observed), so the interruption was most plausibly on the bridge/harness side.
4. When the approval call finally went out, the harness answered "not in plan mode" — the plan-mode state, which lives in-band on the bridge, had evaporated with the interruption.
5. The error path has no recovery: no retry, no re-delivery of the approval request, no re-entry into plan mode. The session simply dropped out of plan mode without delivering the plan.
6. The plan remained stranded in the ephemeral container (reclaimed after inactivity). We recovered it manually by asking for it in the cloud session's chat before the container was reclaimed; a day later it would likely have been gone.
7. Additional finding from a follow-up session on 2026-07-25: the cloud container had no git remote and no push credentials configured, so even the "push it to origin" escape hatch was unavailable in that environment.

What Should Happen?

Expected behavior

Any one of these would have prevented the loss:

• Plan-mode / approval state persisted server-side (or rehydrated on reconnect) instead of living only in the in-band bridge connection.
• A retry / re-delivery path when the approval call fails with "not in plan mode" — at minimum, re-entering plan mode and re-offering the plan instead of silently dropping out.
• On handoff failure, the plan auto-saved to a durable location: committed to a branch (when the environment has git credentials) or attached to the conversation, with a pointer in the error message.

Actual behavior

The plan was completed but never delivered; the session exited plan mode with no recovery, and the only copy lived in an ephemeral container's filesystem.

Impact

Loss of a full planning session's output unless the user notices in time and manually extracts the plan from the cloud session's chat. The failure occurred under ideal client conditions (stable laptop + Warp + tmux), so it is not mitigable by client-side hygiene alone.

Error Messages/Logs

Approval tool call failed with: "not in plan mode"
(The plan-approval request was rejected by the harness after the turn was split by the deferred tool
load; no retry / re-delivery was attempted. Full session logs are unavailable — the session ran in an
ephemeral cloud container that has since been reclaimed.)

Steps to Reproduce

1. On a Linux host (Ubuntu VPS, inside tmux, accessed over SSH from a laptop via Warp), start Claude

Code CLI and launch a remote planning session (plan refinement running in an ephemeral cloud container).

1. Let the session finish writing its plan. At this point the plan exists only in the cloud container's

filesystem.

1. The plan-approval tool is deferred: loading it requires an extra round-trip. In our case the turn was

interrupted inside that window (client connection was stable) and the tool-load result arrived as a new
turn.

1. The subsequent approval call fails with "not in plan mode". The session drops out of plan mode with

no retry or re-delivery; the completed plan is never delivered and remains stranded in the ephemeral
container.

Note: timing-dependent, not deterministically reproducible — the failure window is the gap between "plan
ready" and "approval request sent", widened by the deferred tool load. It occurred with a stable client
(laptop + Warp + tmux over SSH).

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.220 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Warp

Additional Information

_No response_