Terminal tool corrupts multiline commands exceeding 1024 bytes

[jcansdale]

Bug

The terminal tool (run_in_terminal) corrupts any multiline command exceeding 1024 bytes. After byte 1024, content wraps around and replays earlier buffer content, destroying the remainder of the command and leaving the shell stuck in quote> or heredoc> mode.

Minimal Reproduction

Ask Copilot to run this in the terminal (19 lines × 55 chars + wrapper = 1077 bytes):

echo 'L01 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L02 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L03 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L04 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L05 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L06 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L07 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L08 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L09 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L10 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L11 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L12 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L13 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L14 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L15 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L16 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L17 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L18 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
L19 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' | wc -c

Expected: Outputs 1064
Actual: L19 becomes garbled (L19 aaaaaL02 aaa...), closing ' is lost, shell stuck at quote>

Reduce to 18 lines (1021 bytes) → works perfectly. The boundary is exactly 1024 bytes.

Verified Facts

Test case	Result
18 lines × 55 chars (1021 bytes), multiline	✅ Works
19 lines × 55 chars (1077 bytes), multiline	❌ Corrupts at byte 1024
Same 20-line content via $'...\n...' (1156 bytes, single-line)	✅ Works
Single line of 2000+ chars	✅ Works
cat << 'EOF' heredoc > 1024 bytes	❌ Corrupts at byte 1024
python3 -c "..." multiline > 1024 bytes	❌ Corrupts at byte 1024

The corruption only affects multiline commands (containing literal newline characters) and always occurs at exactly byte 1024.

Why This Is a Serious Problem

The failure mode is cascading and difficult to recover from:

1. Silent corruption: The tool reports success ("The tool simplified the command to...") but the shell receives garbled data. The agent has no way to detect this before it happens.

2. Shell gets permanently stuck: The closing delimiter (', ", EOF) is lost in the corruption, so the shell enters quote> or heredoc> mode. Every subsequent command the agent sends is swallowed as continuation of the broken quote — the terminal is bricked until a new one is opened.

3. Extremely common trigger: 1024 bytes is a very low threshold. Any of these routine operations can exceed it:

   • gh issue create --body '...' or gh pr create --body '...' with a detailed description
   • Heredoc writes (cat > file << 'EOF')
   • Inline Python/Node scripts (python3 -c "...")
   • Any multiline shell script pasted to the terminal

4. Hard to diagnose: The garbled output looks like random gibberish — fragments of earlier content mixed with later content. Without knowing about the 1024-byte boundary, this appears to be a non-deterministic, unreproducible glitch. (We initially filed and closed a report as "unreproducible" before discovering the byte-count trigger.)

5. Recovery makes things worse: When the agent sees an error or stuck shell, it typically retries. But the terminal is stuck in quote mode, so retries just feed more text into the broken quote, creating increasingly bizarre output and wasting tokens.

Root Cause Hypothesis

The terminal tool uses a different input mechanism for multiline commands (likely bracketed paste or line-by-line writing to the PTY) compared to single-line commands. This multiline path appears to use a 1024-byte buffer — a classic PIPE_BUF or PTY canonical-mode buffer size — that wraps on overflow rather than flushing and continuing.

Environment

• VS Code Insiders
• macOS
• zsh
• Copilot agent mode (Claude)

[meganrogge]

I cannot reproduce the issue

[jcansdale]

Confirmed reproduction on VS Code Insiders (macOS, zsh, Claude).

Running the exact 19-line test case from the issue via the terminal tool:

Attempt	Result
1	✅ Worked (output 1064)
2	❌ Corrupted — L19 became L19 aaaaaL02 aaa..., shell stuck at quote>
3	❌ Failed — command swallowed by stuck quote from attempt 2

The corruption pattern matches exactly: content after ~byte 1024 replays earlier buffer data, the closing ' is lost, and the shell enters quote> mode. Once stuck, every subsequent command is consumed by the broken quote.

Key observation: The bug is intermittent — the same command can succeed once and fail the next time. This may explain difficulty reproducing. The heredoc variant (cat << 'EOF') seemed to fail more consistently in my testing.

Important: This must be tested via the terminal tool, not by pasting into a terminal window. To reproduce:

1. Open Copilot in agent mode
2. Ask: "Run this exact command in the terminal:" followed by the 19-line echo from the issue
3. Repeat if needed — it may take 2-3 attempts to trigger

[jcansdale]

@meganrogge,

Thanks for taking a look! I'm sorry you weren't able to repro.

Can you try the following prompt with Claude Opus 4.5?

Have a look at this issue and see if you can repro:
#296955

I'm wondering if which model you use might impact how often it occures. 🤔

[meganrogge]

Still doesn't repro. Any model

[jcansdale]

@meganrogge I was able to reproduce this on both my M1 work Mac (macOS 15) and an older Intel-based Mac (macOS 13). I've created a standalone reproducer that confirms this is a macOS PTY bug, not specific to VS Code:

Repo: https://github.com/jcansdale/macos-pty-multiline-bug

The Python script uses pty.openpty() + os.fork() to spawn an interactive shell and writes multiline data directly — no VS Code involved. On macOS, os.write() blocks when multiline input exceeds ~1024 bytes due to PTY backpressure from the shell's line editor.

CI results: Both macOS 15 and macOS 14 fail, Ubuntu passes.

Lines	Bytes	macOS	Linux
18	~1005	✅	✅
20	~1115	❌ BLOCKED	✅
25	~1390	❌ BLOCKED	✅

While the root cause is in macOS, this seriously hamstrings a lot of Copilot agent workflows — any multiline terminal command over ~1KB (heredocs, long git commit messages, python3 -c scripts, etc.) corrupts the terminal and leaves it stuck.

Potential fix in VS Code: Write multiline PTY input in small chunks (e.g. 512 bytes) with brief pauses between writes, rather than a single large write(). This would drain the backpressure between chunks.

[meganrogge]

@jcansdale In your Python repro, Python creates its own PTY (pty.openpty) and writes directly with os.write.
That bypasses VS Code’s terminal input write path (run_in_terminal -> VS Code/node-pty write handling), except for the one short command used to start Python.
So it’s a valid test for the macOS PTY root cause, but not a direct validation of whether a VS Code-side mitigation (like chunked/serialized writes in our input pipeline) is working.
So it’s a valid repro for the platform issue; we just need an additional VS Code-path test to verify the mitigation in this issue - and I still have not found one.

Edit: I just saw an issue

[jcansdale]

@meganrogge, fair point about the Python repro bypassing VS Code's write path. I've added a VS Code extension reproducer that calls terminal.sendText() directly — exercising the full pipeline from extension host through IPC to pty host to node-pty.

It runs in CI via @vscode/test-electron and fails consistently on macOS (both stable and insiders), while passing on Ubuntu:

CI run

Runner	Stable	Insiders
macOS 15	❌	❌
macOS 14	❌	❌
Ubuntu	✅	✅

Example output (macOS):

Lines    Bytes      Pass     Result
5        502        5/5      ✅ OK
10       780        5/5      ✅ OK
18       1220       1/2*     ❌ 1 FAILED (no output file)
20       1330       1/2*     ❌ 1 FAILED (no output file)
25       1605       1/2*     ❌ 1 FAILED (no output file)
30       1880       1/2*     ❌ 1 FAILED (no output file)

Small commands (≤10 lines, <1KB) pass 100%. Larger multiline commands fail intermittently — when they fail, the terminal gets stuck and produces no output.

Branch: main
Workflow: vscode-repro.yml
Extension source: vscode-extension/