[BUG] --cloud: finished work stranded — session idles with background jobs pending, no push-access warning, held messages reported as sent

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet. Related but not the same: #81776 (--cloud always bundles, no push) and #97813 (feature: attach to a running cloud session).
• [ ] This is a single bug report. It is one incident with three contributing defects, listed below. I can split it if you prefer.
• [ ] I am using the latest version of Claude Code. Seen on 2.1.292; 2.1.295 is current.

What's Wrong?

One unattended --cloud task took three launches and about 3 h 50 min to produce a pushed result. About 2.5 h of cloud runtime produced nothing retrievable:

• Run 1 went idle mid-task with nothing pushed.
• Run 2 finished and committed the work, but couldn't push it.
• We couldn't reach either session from the CLI to unblock it.

1. A cloud session goes idle when its turn ends with background work pending.

• Run 1 started its test suites under Monitor or in background shells, then ended its turn. Nothing woke it, so it sat idle with the work unfinished.
• On teleport, the CLI printed: "Background shell command didn't finish before the previous session ended."
• The tool moves a foreground command to the background once it passes 600 s. So a long test suite can end up in the background without the model choosing it.

2. --cloud from a repo the Claude GitHub App doesn't cover gives no warning that the session can't push.

• The CLI uploaded a bundle. Launch output was only "Created cloud session … View: … Resume with: …".
• Run 2 did about 70 min of work and committed it. Then:
• the checkout had no origin;
• after adding one, git ls-remote asked for a username;
• gh api returned 403 and pointed to add_repo.

3. A cloud session can't be reached from the CLI that launched it.

• Messages are held, but the sender is told they were sent. SendMessage from a local session to the cloud session returned success, twice, but nothing arrived in the cloud transcript.
• In a later run we read the session's event log. The message was logged as peer_message_hold, cause mode-mismatch (the local sender ran in bypassPermissions), and expired about 5 minutes later unapproved.
• The sender never learned it was held or that it expired.
• --help offers an attach that isn't available. claude --help lists --cloud [description|session_id|url] as able to "attach to an existing one by session ID or claude.ai/code URL". claude --cloud <session_id> returned: "Error: Attaching to an existing cloud session is not enabled for your account." That error appears to be expected for some accounts (claude -p "<msg>" --cloud <id> is the supported form), so the defect is that --help offers the attach unconditionally.
• Teleport leaves unpushed commits behind. claude --teleport resumes the conversation locally, but the container's unpushed commits don't come with it. The only way to recover the finished work was to run the whole task again.

What Should Happen?

1. An unattended cloud session either:

• stays alive until its own background jobs and Monitors finish, then resumes; or
• at least shows "idle, background work pending" where the launcher can see it.

1. --cloud from a repo without push access warns at launch, or refuses: "this session won't be able to push; install the Claude GitHub App on <repo>".
2. On reaching a cloud session:

• A held message is reported to the sender as held, and again if it expires.
• --help shows attach only where it works, and names the -p form otherwise.
• Unpushed commits can be recovered, for example as a bundle through teleport, before the container is reclaimed.

Error Messages/Logs

Background shell command didn't finish before the previous session ended.
Error: Attaching to an existing cloud session is not enabled for your account.
gh api: HTTP 403 (pointed to add_repo)
session event: peer_message_hold  cause=mode-mismatch  outcome=expired

Steps to Reproduce

1. Run claude --cloud "<a task with a test suite longer than 10 minutes>" --model claude-sonnet-5-5 --effort high from a local clone of a private GitHub repo that the Claude GitHub App is not installed on.
2. Observe:

• no warning about push access at launch;
• the session ends its turn while the suite runs in the background, and goes idle;
• when it does finish, git push fails (no origin, then credential prompt, then 403).

1. From a local session in bypassPermissions mode, SendMessage to the cloud session. It returns success. The cloud event log shows peer_message_hold (mode-mismatch), then expired, and the sender is not told.
2. claude --cloud <session_id>: error as above, though --help offers it.
3. claude --teleport <session_id>: the conversation resumes, but the unpushed commits are not retrievable.

Claude Model

Sonnet 5.5 (cloud runs), Opus 5.5 (local sender)

Is this a regression?

I don't know

Claude Code Version

2.1.292 (Claude Code)

Platform

Anthropic API (Max plan)

Operating System

macOS (Darwin 25.6.0)

Additional Information

• Since installing the GitHub App and briefing sessions to run everything in the foreground and write their report to a file, later cloud tasks on the same repo pushed without help.
• Suggested fixes, by value:

1. a push-access check at launch;
2. no idle while the session's own background jobs are pending;
3. a sender notice when a message is held or expires;
4. a way to recover unpushed commits.