[BUG] Desktop: a command sent by the Run (▷) button is held until the session tab regains focus — the integrated terminal's shell PTY appears to start on focus

What's Wrong?

Pressing the Run (▷) button on a code block in a desktop Code session does not run the command. The command is silently held. It reaches the integrated terminal only when the user switches to another local session tab and comes back — and then it runs within one second of the tab regaining focus.

Nothing fails visibly: no error, no warning, the button looks like it worked. The only symptom is that nothing happens, for as long as the user stays on the tab.

Measured waits so far: 0.8 s, 0.86 s, 2 min 45 s, and 17 min — in every case the command executed 0–1 s after focus returned to the session, never before.

Evidence — controlled experiment

The probe is a single line with no side effects, so nothing else can explain the timing:

Write-Host ("PROBE " + (Get-Date).ToString('HH:mm:ss.fff'))

| Time | Event | Source |
|---|---|---|
| 18:03:03 | ▷ pressed | user report (see note below) |
| 18:03:03–18:03:11 | terminal watched continuously for 8 s — no output | direct observation |
| 18:03:53 | switched to another local session | setFocusedSession in main.log |
| 18:03:55 | switched back to this session | setFocusedSession in main.log |
| 18:03:55.859 | command ran — 0.86 s after refocus, 52 s after the press | timestamp printed by the command itself |

The printed timestamp comes from the command, so it records when the shell actually ran it, not when it was rendered.

Note on the press: we could not find any log entry that corresponds to the ▷ dispatch itself. The only main.log entry at 18:03:03 is a LocalSessions.sendMessage with messageLength=4, which is too short to be this command and is followed by the ordinary chat-send path (Sending message to session → Mapping internal session … to CLI session …). So the press time above rests on the user's report, not on the log. If ▷ dispatch is expected to be logged, its absence may itself be worth checking.

What the log does show: the terminal's shell starts on focus

Across one day of normal use on this machine, setFocusedSession is followed by startShellPty for the same session within 0–1 s, repeatedly, for 15 different sessions. Examples:

18:14:42  setFocusedSession: <session-A>
18:14:43  startShellPty:     <session-A>
18:24:59  setFocusedSession: <session-A>
18:24:59  startShellPty:     <session-A>
18:25:42  setFocusedSession: <session-B>
18:25:42  startShellPty:     <session-B>

The same shape appears inside the experiment window above:

18:03:53  setFocusedSession: <other-session>
18:03:54  startShellPty:     <other-session>
18:03:54  [WarmLifecycle:session] Starting idle timeout for <probe-session>: 900s
18:03:55  [WarmLifecycle:preview] Warming up session <probe-session>
18:03:55  setFocusedSession: <probe-session>
          (command executed at 18:03:55.859)

We are reporting this as an observed correlation, not a diagnosis: we did not instrument the dispatch path itself. But if the integrated terminal's shell PTY is started when a session gains focus, and the session is put on an idle timeout when it loses focus, then a command dispatched to an unfocused session has nothing to arrive at until focus returns — which matches every measurement above.

Ruled out by evidence

• Permission approval. In one instance the command completed 5 s before the permission response was recorded. In two others no permission prompt was ever emitted.
• Terminal busy. The panel was idle at a prompt throughout.
• Slow tool. The same command invoked without ▷ completes in 0.44–1.3 s (5 measurements).
• Ran immediately on press. The probe sat unexecuted for 52 s, with the press time independently reported and the terminal watched continuously.
• Chat activity flushes it. Sending a chat message does not release the held command; only a tab refocus does.

Reproduction

1. Open a local Code session in the desktop app with the integrated terminal visible. Have at least one other local session open in the same window.
2. Get a runnable code block into the conversation, e.g. the probe line above.
3. Press ▷. Do not click, scroll, or switch anything afterwards.
4. Watch the terminal for 30 s — the command does not run.
5. Switch to any other local session tab, then switch back.
6. The command runs within ~1 s of returning. The timestamp it prints shows how long it was held.

What Should Happen?

A command dispatched by ▷ should reach the terminal when the button is pressed, independent of which session tab currently has focus. If dispatch genuinely must wait on something, the button should show that the command is pending rather than appearing to have done nothing.

Impact

Any workflow that hands the user a one-click command becomes unreliable: the user presses the button, nothing happens, and the natural conclusion is that the underlying tool is broken. We misdiagnosed our own tooling three times before instrumenting the press-to-execution path and finding the hold.

Environment

• Claude Desktop 1.34493.1 (Windows 11 Pro, build 26200)
• Embedded CLI 2.1.237
• Integrated terminal: powershell.exe 5.1 over ConPTY
• Several local Code sessions open in the same app instance
• Log location note: main.log is now written to %LOCALAPPDATA%\Claude\logs\main.log. The older %APPDATA%\Claude\logs\main.log on this machine stops at the moment of an app update and is no longer written to, so it looks empty for recent activity.

Related

• 36418 — closed as a duplicate; same "does not progress while unfocused" shape, but reported for the terminal client, not the ▷ button
• 25068 — the duplicate target, closed NOT_PLANNED
• 84315 — integrated terminal never binds in a restored session (there the panel is absent; here the panel works and the command does not arrive)
• 74889 — sessions silently reject commands, cloud sessions only
• 42921 — closed NOT_PLANNED; multiple Windows Desktop sessions sharing one CLI instance, reported while starting sessions with the run button
• 62559 and 64233 — earlier Windows regressions where focus changes affected unfocused sessions