You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bug: #67 Still Not Fixed - Restart Session Does Not Recover Remote Agent After Auto-Continue Limit #72
On a Remote SSH Workspace, the agent sometimes reaches the auto-continue limit:
Auto-continuing (1/3) - resuming on remote...
Auto-continuing (2/3) - resuming on remote...
Auto-continuing (3/3) - resuming on remote...
Agent did not complete after 3 auto-continues
After this happens, the chat no longer responds.
Using "Restart Session" does not recover the conversation.
Environment
Claude Code Studio v7.x
Windows 11
Remote SSH Workspace
Linux remote host
Steps to Reproduce
Open a Remote SSH Workspace.
Start a conversation or task.
Wait until auto-continue is triggered.
Let the retries reach 3/3.
Observe the failure message.
Try "Restart Session".
Actual Behavior
Auto-continue reaches its limit.
The agent stops responding.
Restart Session does not recover the chat.
No obvious recovery mechanism is available.
Expected Behavior
The chat should remain usable after the failure.
Restart Session should fully recover the agent.
The SSH session should be reconnected automatically when possible.
The user should be able to continue the conversation without creating a new chat.
Suggestions
Display the root cause of the failure.
Show SSH connection status.
Add a "Reconnect SSH Session" action.
Automatically recreate the remote agent when the SSH connection is still available.
Provide more detailed logs when auto-continue fails.
Impact
This is disruptive for long-running tasks on remote SSH workspaces because the conversation becomes permanently stuck and must often be recreated from scratch.
Thanks for filing again — and you were right to. This is the same report as #67, opened about three hours before v7.11.0 shipped, and that release changes something important here even though it does not claim to fix the root cause.
Why this was hard to diagnose, which is itself a defect
The remote auto-continue path logged nothing at all. Not on the max_turns branch, not on the non-success one. The local CLI loop has logged since it was written; the SSH one never did. So this failure left no trace on the server, which is why the earlier round came down to reading your chat transcript and guessing.
That is fixed. ssh-auto-continue now records turnsUsed, requested, durationMs and the stop subtype on every retry, plus an ssh-turn-budget-anomaly warning.
The number in your log that does not add up
Your run reported 3 turns, and in #24 you mentioned working with Turns=50.
Measured against CLI 2.1.231: a run capped at N reports num_turns === N + 1. A genuine exhaustion therefore lands at the cap — never at a fraction of it. Stopping after 3 turns against a 50-turn dial means the cap being hit is not the one in this chat, so "raise Max turns" was actively wrong advice.
v7.11.0 says that instead, and says it on the first retry rather than after all three are spent:
the run stopped after 3 turns although it was given 50 — the turn limit is NOT coming from this chat's "Max turns", so raising it will not help. Check the Claude CLI version and any settings.json / hooks on the machine the agent runs on.
On "Restart Session does not recover"
In the transcript you posted on #67, it could not have helped: the chat was not stuck. That turn ended on its own — ✅ Done — 8 calls is in the same log. Restart Session clears claude_session_id so the next message starts a fresh Claude session with your history replayed; it does not change how many turns the remote CLI is willing to take. The wording that offers it after an exhausted auto-continue is misleading in exactly this case.
(The genuinely stuck variant — where the session refuses every new message and Restart answers "Task is still running" — was a missed termination in the SSH transport, fixed in 7.9.0 (#68). If you still hit that specific symptom, it is a separate bug and worth its own report.)
What I need to close this properly
The root cause is still not established, and I would rather ask than guess again. On v7.11.0, when it next happens:
The Max turns value in that chat (a screenshot of the toolbar is fine).
Server log lines: grep -E 'ssh-auto-continue|ssh-turn-budget-anomaly' <logfile>.
ssh <host> 'claude --version' — the CLI version on the remote host, not the local one.
Whether the same thing happens on a local project, or only on the remote one.
Item 2 is the one that did not exist before this release. With it, this stops being guesswork.
Closing this as a duplicate of #67 to keep the discussion in one place — please reply here or there with those four items and I will reopen and dig in.
Activity
Lexus2016 commentedon Aug 25, 2026
Thanks for filing again — and you were right to. This is the same report as #67, opened about three hours before v7.11.0 shipped, and that release changes something important here even though it does not claim to fix the root cause.
Why this was hard to diagnose, which is itself a defect
The remote auto-continue path logged nothing at all. Not on the
max_turnsbranch, not on the non-success one. The local CLI loop has logged since it was written; the SSH one never did. So this failure left no trace on the server, which is why the earlier round came down to reading your chat transcript and guessing.That is fixed.
ssh-auto-continuenow recordsturnsUsed,requested,durationMsand the stopsubtypeon every retry, plus anssh-turn-budget-anomalywarning.The number in your log that does not add up
Your run reported
3 turns, and in #24 you mentioned working withTurns=50.Measured against CLI 2.1.231: a run capped at N reports
num_turns === N + 1. A genuine exhaustion therefore lands at the cap — never at a fraction of it. Stopping after 3 turns against a 50-turn dial means the cap being hit is not the one in this chat, so "raise Max turns" was actively wrong advice.v7.11.0 says that instead, and says it on the first retry rather than after all three are spent:
On "Restart Session does not recover"
In the transcript you posted on #67, it could not have helped: the chat was not stuck. That turn ended on its own —
✅ Done — 8 callsis in the same log. Restart Session clearsclaude_session_idso the next message starts a fresh Claude session with your history replayed; it does not change how many turns the remote CLI is willing to take. The wording that offers it after an exhausted auto-continue is misleading in exactly this case.(The genuinely stuck variant — where the session refuses every new message and Restart answers "Task is still running" — was a missed termination in the SSH transport, fixed in 7.9.0 (#68). If you still hit that specific symptom, it is a separate bug and worth its own report.)
What I need to close this properly
The root cause is still not established, and I would rather ask than guess again. On v7.11.0, when it next happens:
grep -E 'ssh-auto-continue|ssh-turn-budget-anomaly' <logfile>.ssh <host> 'claude --version'— the CLI version on the remote host, not the local one.Item 2 is the one that did not exist before this release. With it, this stops being guesswork.
Closing this as a duplicate of #67 to keep the discussion in one place — please reply here or there with those four items and I will reopen and dig in.
Lexus2016 commentedon Aug 25, 2026
Duplicate of #67 — the detail is in the comment above. Reopening the moment those four items land, here or on #67.