VS Code extension (macOS arm64): prompt submit button stays idle while the session runs headless → invisible double-execution

Summary

On the macOS VS Code extension, submitting a prompt sometimes leaves the submit/“go” button in its idle (not-in-progress) state, while a session actually starts and runs headless in the background — making git commits, pushing branches, opening PRs, and even merging them — with no visual indication in the UI that anything is running. Because the UI looks idle, the operator re-submits or starts a new session, producing two sessions executing the same task in parallel (double-execution). In our case a hidden session autonomously merged a PR while the visible session believed nothing was running.

Environment

• Extension: anthropic.claude-code-2.1.172-darwin-arm64
• OS: macOS 26.5.1 (build 25F80), Apple Silicon (arm64, M4)
• VS Code, single window. All native-binary/claude session processes share one extension-host parent (ppid).

Steps to reproduce (intermittent, only seen on the M4 Mac)

1. Open a new Claude Code session in the VS Code panel.
2. Paste a long prompt (a multi-section “handoff”) and click the prompt’s submit/go button.
3. Observe: the button does not transition to the in-progress/working state — the panel looks idle/fresh.
4. In reality a session process has started and is working (verifiable: ps -axo pid,etime,command | grep native-binary/claude shows an active process; ~/.claude/projects/<encoded-cwd>/<uuid>.jsonl is being written; git commits appear on a branch no visible session authored).

Expected vs actual

• Expected: clicking submit transitions the button to the working/in-progress state, and the running session is visible in the UI; or, if the session can’t be attached to the UI, the extension surfaces it (e.g. in Session history as “active”).
• Actual: the button stays idle; the session runs invisibly; the operator cannot tell a session is active, cannot attach to it, and cannot stop it from the UI without closing the whole tab/window.

Impact

• Double-execution / unsupervised irreversible actions. Believing nothing started, the operator starts a second session on the same task. Two sessions then race; one can push/merge PRs while the operator thinks no session is running. (We hit exactly this: a hidden session merged a PR + a follow-up branch to develop unsupervised.)
• There is currently no documented first-class way to (a) list live/background sessions (the --resume picker and “Session history” only show saved sessions), (b) attach the UI to an already-running session, (c) kill a specific session by id, or (d) prevent a second concurrent session on the same workspace. The only reliable detection we found is OS-process + git-behavior inspection, and the only surgical recovery is kill <pid> after deriving the process tree.

Questions / requests

1. Is the “submit button stays idle while the session runs headless” a known macOS-extension regression in the 2.1.17x line?
2. Could the extension reliably transition the button to in-progress on submit (the core fix), and surface/attach live background sessions in the UI?
3. A lighter mitigation that would help a lot: a way to list active sessions for the workspace and stop one by id without killing the extension host, and/or a single-session-per-workspace guard that warns before starting a duplicate.

Happy to provide more detail / logs if useful.