[BUG] #800

Activity

1. juneleung

   added the

   Bug

   issue type on Jul 4, 2026
2. juneleung

   added

   bugSomething isn't workingSomething isn't working

   on Jul 4, 2026
3. edelauna commented on Jul 5, 2026

   

   edelauna

   on Jul 5, 2026

   Contributor

   More actions

   Investigation findings

   Root cause confirmed: VSCode's shell-integration API can silently fail to signal command completion. onDidEndTerminalShellExecution never fires and the execution.read() stream never closes on its own for certain command shapes — even though the command has genuinely finished. In the worst case, VSCode delivers zero stream data at all (not even the start marker), confirmed via a controlled, 100%-reproducible e2e test against a real, non-mocked VS Code instance.

   Fix: PR #834 — TerminalProcess now detects the ]633;D completion marker directly in the accumulated stream data as it arrives, and self-finalizes as soon as it sees it, independent of whether the stream/event ever confirms completion. It waits a brief grace period for the real exit-code event, and proceeds without one if it doesn't arrive.

   An earlier version of the fix included a 15s idle-timeout as a fallback for the case where even the marker never arrives. That was reverted after live testing showed it fires falsely on legitimate long-running, quiet commands (e.g. a cold tsc --noEmit on a large project takes ~24s with zero interim output — indistinguishable from the broken-signal case by elapsed time alone). We chose not to guess a threshold that would trade one class of false positive for another.

   Also fixed: a late/stale onDidEndTerminalShellExecution event for an already-superseded execution could be misapplied to whatever command is currently running on a reused terminal, corrupting its exit code. TerminalRegistry now tracks each process's own execution identity and ignores stale events.

   Known residual gap

   Some command shapes reliably cause VSCode to emit zero stream data at all, confirmed for:

   • A multi-line command containing a literal embedded newline (e.g. python3 -c "..." with real \ns), which we auto-wrap into { ...\n... } for correctness reasons
   • A ( ... ) subshell wrapper (not something we generate ourselves, but a model could emit one)

   For these, VSCode's own onDidStartTerminalShellExecution event was observed reporting a corrupted command field — the script's own stderr output was concatenated directly into what VSCode thinks is the command-line string. That's direct evidence this is a VSCode-internal shell-integration parser bug, not something we can address by changing our own command-wrapping strategy. Manual live testing after the fix confirmed: normal long-running quiet commands now behave correctly, but this specific narrow class of command shape can still hang, requiring a window reload as before.

   We're preparing an upstream VS Code bug report with this evidence (clean repro + the corrupted command-line finding) since it's more precise than existing related reports we could find.

   PR: #834
4. edelauna commented on Jul 5, 2026

   

   edelauna

   on Jul 5, 2026

   Contributor

   More actions

   Filed the upstream VS Code report with the corrupted-command-line evidence: microsoft/vscode#324392
5. github-merge-queue

   added a commit that references this issue on Jul 14, 2026

   fix(terminal): fix output loss on cold terminals by moving read() int…

   ...

   7d0879b
6. edelauna

   closed this as completedin #834on Jul 14, 2026