bash tool hangs on large multiline commands (heredoc writes time out, file never created)

[terry2010]

Summary

On the desktop app (dsh 0.2.1-rc.3, macOS arm64), bash tool calls that carry a large multi-line command — e.g. a ~17 KB cat > file << 'EOF' … EOF heredoc or a ~15 KB python3 -c script — never execute. The call hangs until the 300 s timeout and is killed, and the persistent shell can be left in a continuation state that hangs subsequent commands as well. Small single-line commands work fine.

Observed live: an agent tried mkdir → cat > file << EOF → cat|head → ls → python3 -c → chunked heredoc. Only the small commands ran; every file-writing attempt timed out and the file was never created.

Session journal evidence

Workspace /Volumes/2t/code/polly-subtitle-translator, preset workspace-write:

seq	command	args size	result
44	mkdir -p "<ws>/鹈鹕"	small	OK, dir created
48	cat > "<ws>/鹈鹕/qwen3.6.moe.html" << 'HTMLEOF' (+ ~16.9 KB HTML)	16,943 chars	timed out after 300 s; retained output shows only the dsh> prompt; file not created
54	cat "<ws>/鹈鹕/qwen3.6.moe.html" | head -20	small	OK — No such file or directory
59	ls -la "<ws>/鹈鹕/"	small	OK — empty dir
63	python3 -c "html_content = '''<same html>''' …"	~15.5 KB	timed out after 300 s
73	chunked cat > qwen3.6.moe.html << 'PART1'	~1.7 KB	also hung

The recorded arguments for seq 48 are complete and well-formed — the JSON-encoded command ends with the HTMLEOF terminator. So the model emitted a valid command; the tail of the input appears to be lost somewhere between the tool call and the shell's parser.

Suspected cause

bash is backed by a persistent interactive PTY shell (/bin/bash --noprofile --norc -i, controlled prompt dsh> ). Sending a large multi-line command through the tty apparently drops trailing bytes, so the heredoc/quote terminator never arrives: the shell keeps waiting for input, the command never runs (the > redirection only executes after the heredoc is fully parsed — consistent with the file never being created), and the executor waits for the next dsh> prompt until the 300 s timeout.

Suggestions

• Feed commands to the shell through a non-tty channel (pipe/sh -c), or chunk the input with backpressure instead of one large write.
• Enforce a documented max command size and fail fast with a clear error rather than a 300 s hang.
• On timeout, fully reset the shell (interrupt + drain pending input) so later calls don't inherit a poisoned continuation state.
• Consider steering the model toward write/edit tools for file creation instead of bash heredocs.

Environment

• dsh 0.2.1-rc.3, official desktop app, macOS arm64 (Darwin 27)
• Session preset workspace-write; all writes here target paths inside the workspace, so the file sandbox is not the cause
• Workspace lives on an external APFS volume mounted noowners (likely unrelated)
• Happy to attach the raw session journal (session.v4.jsonl.zstd) if useful

[terry2010]

Follow-up with a local reproduction — the mechanism is now confirmed.

Root cause: bash tool commands are written as ONE node-pty write into a persistent interactive shell (subprocess-local/src/terminal.ts → terminal.write(text + '\r')). On macOS a single large write to a pty master loses its tail — the heredoc/quote terminator never reaches the shell, so it waits for input forever; the command never runs; the executor waits for the dsh> prompt until timeout.

Reproduction (node-pty + /bin/bash --noprofile --norc -i, output drained continuously):

input	result
cat > f << EOF heredoc, ~600 B	works
same, ~2 KB	works
same, ~16 KB single term.write()	fails — file never created, shell left in heredoc continuation
same 16 KB in 512 B chunks	works
python3 -c ~15 KB single write	fails

A raw non-blocking write() to a pty master on this system accepts only ~1022 bytes before EAGAIN — consistent with the observed truncation.

Shell-agnostic: identical failure with /bin/bash 3.2.57, Homebrew bash 5.3.20 and /bin/zsh — the bytes are dropped in the kernel/node-pty write path before any shell reads them, so switching the configured shell does not help.

Secondary effect: after a timeout the interactive shell keeps waiting inside the unterminated heredoc — later commands are swallowed as heredoc body, which is why even a ~1.7 KB retry also hung. The timeout path should reset the shell (interrupt + drain pending input) so subsequent calls recover.

Fix direction: chunk PTY input with drain/backpressure, enforce a max command size with a clear error, or route non-interactive commands through an argv-based bash -c executor instead of the PTY.

[PerryLink]

The shell never sees a heredoc. That changes the mechanism.

wrapCommand at packages/shell/tool-bash-persistent/src/index.ts:82-87 flattens each call onto one physical line: printf …; eval -- '<your command>'; …. Everything bash parses comes from that single-quoted argument, not from stdin lines. So when the tail of the write is lost, bash is not inside a heredoc body — it is waiting for the closing quote of the argument. That is why no statement runs, why the file never appears, and why whatever arrives next joins the same unterminated string.

The write path is exactly as you traced, one layer lower: packages/terminal/terminal-bash/src/session.ts:391 builds ${text}${submit ? '\r' : ''} and hands it to terminal.write once (:394); packages/subprocess/subprocess-local/src/terminal.ts:141-145 forwards it to node-pty as a single this.terminal.write(data). No cap, no chunking, no drain in between.

Two parts of the report do not hold on the current code.

• The timeout path already resets the shell: :358 calls shells.reset(...), which reaches ctx.terminals.kill (:231-234), and the result appends SHELL_RESET_MESSAGE (:19). A poisoned shell therefore does not survive into the next tool call — every call after a timeout spawns a new one. It only survives the remainder of the same call, where the loop re-sends an empty string and waits for the end marker.
• The ~1.7 KB "chunked heredoc" retry hung for a different reason: a heredoc split across two calls can never close. The first call is wrapped, evaluated, and killed at timeout; the second call starts fresh with no memory of the first.

So the useful half of your suggestion is the input side — chunk inside write() and await between chunks (write already returns a promise, so the contract is there), and cap the command size in the tool so an oversized call fails in a second instead of at 300.