### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? ### Summary On Claude Desktop (macOS), **existing sessions open and display their history, but typed commands are never executed.** Nothing runs, no erro

## Bug: Existing (cloud) sessions open in Claude Desktop but silently reject commands — no `sendMessage`/`startShellPty` fires

Open 💬 0 comments Opened Jul 6, 2026 by stefanprtina

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?

Summary

On Claude Desktop (macOS), existing sessions open and display their history, but typed commands are never executed. Nothing runs, no error is shown. A new session created in the same window works normally. The affected sessions are the session_01… (claude.ai/cloud) entries in the session list; freshly created local sessions run fine, so the local VM runtime itself is healthy.

Separately, I found the app had gotten into a state where existing sessions could not be opened at all until a local state flag was flipped (details in "Secondary finding" below) — the "won't run commands" bug is what remains after that.

Environment

Claude Desktop: 1.18286.0 (259c3f), build date 2026-07-02
OS: macOS (Darwin 25.2.0), Apple M1 Pro (arm64)
Bundled Cowork/claude-code-vm runtime (SDK): 2.1.197
Standalone Claude Code CLI on PATH: 2.1.201 (works perfectly, unaffected)

Expected

Sending a command in an existing session runs it, same as a new session.

Actual

Existing session: command is accepted by the UI but never executes. No output, no error, no spinner resolution.
New session: works normally.
A full ⌘Q + relaunch does not fix the existing sessions (new still works, existing still doesn't).

Diagnostic evidence (from `~/Library/Logs/Claude/main.log`)

When sending a command to an existing session, the only log activity is session focus + auth + a handoff publish — the message never reaches the session runtime:

[CCD] LocalSessions.setFocusedSession: sessionId=session_01PRZ…
[oauth-v2] using cached token for orgId=…
handoff: publishing session_01PRZ…

There is no LocalSessions.sendMessage and no LocalSessions.startShellPty.

For comparison, a working session shows the full path:

LocalSessions.startShellPty: sessionId=local_…, cols=80, rows=24
LocalSessions.sendMessage: sessionId=local_…, messageLength=…

So for existing/cloud sessions the input dies before the session manager — the session is treated as a published/handoff (remote-attached) session, and input is routed to a transport that has no live runtime attached, rather than spawning a local PTY.

Supporting detail on why it looks like a local-vs-cloud split:

On-disk local session store (~/Library/Application Support/Claude/claude-code-sessions/<acct>/<org>/) contains only local_… records (bound to a cwd/cliSessionId).
The session_01… ids being opened are not in that store — they resolve from the claude.ai web layer (IndexedDB/https_claude.ai_* + HTTP cache).
The local Cowork VM is healthy (boots, network up, SDK installed: version=2.1.197, API reachability: REACHABLE), which is consistent with new/local sessions working.

Secondary finding (may be related, or a separate bug)

Before the above, existing sessions could not be opened at all — only new ones could be created. The sessions-bridge was disposing itself on init:

[sessions-bridge] Disposing (pref disabled or gate off)
[CCD] LocalSessions.setFocusedSession: sessionId=null

Root cause was enabled: false in ~/Library/Application Support/Claude/bridge-state.json (with userConsented: true). The bridge only stays up when enabled && <server gate> && !hipaaRestricted. Setting enabled: true (app quit, edit, relaunch) restored the ability to open existing sessions and produced [sessions-bridge] … reconnected successfully. It did not restore the ability to run commands in them — that's the primary bug above.

Two concerns worth maintainer input:

It's unclear what flipped enabled to false (an update? a UI toggle?), and there was no user-facing indication that opening existing sessions was disabled.
After re-enabling, existing sessions are viewable but non-interactive, which is confusing UX (looks functional, silently isn't).

Workaround

The CLI resumes and runs any of these sessions correctly:

claude --resume        # picker
claude -r <session-id>

Impact

Existing conversations can be read in Desktop but not continued. Only newly created sessions are usable, forcing a fallback to the CLI to continue prior work.

What Should Happen?

I should work normally in cli sessions from desktop app (as I have before)

Error Messages/Logs

Steps to Reproduce

Open Claude Desktop with existing sessions in the list.
Click an existing session (a session_01… / cloud-origin one). Its history loads correctly.
Type a command and press send.
Create a brand-new session and send a command.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.201

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

View original on GitHub ↗