[BUG]

[juneleung]

Describe the bug
To ensure that users can better see the terminal window, I chose not to use inline windows. Without using an inline terminal, ZooCode launches a terminal to run the program, but it cannot capture the results to continue inference. The conversation is also suspended. New input is queued, but because the terminal results are never returned, the program is stuck and cannot be submitted. Is this a bug? Thank you!
To Reproduce
Steps to reproduce the behavior:

1. Execute prompt that requires command-line debugging and let agent handle it automatically.
2. During the response process, model will automatically launch a new terminal window, and the dialog will display "Running".
3. The terminal execution will finish, but the dialog will not capture the terminal's execution result.
4. More information entered manually will only be added to the queue, but the dialog cannot continue because it is suspended and stuck at the step.3

Expected behavior
Capture the results of the automatic execution and continue running.

Screenshots

Video
N/A

What version of zoo are you running
Version: 3.66.0 (a5a490a)

Additional context
vscode Version: 1.126.0 (Universal), MacOS

[edelauna]

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

[edelauna]

Filed the upstream VS Code report with the corrupted-command-line evidence: microsoft/vscode#324392