[0.2.1-rc.3 follow-up] 970-char CJK heredoc hangs persistent bash for 300s; Agent Teams looks stuck after all children finish

[tiramisugg]

Summary

On DeepSeek Harness Desktop 0.2.1-rc.3 (bundled DSH 0.1.208, macOS 26.6.2 arm64), a short bash call (970 characters) containing a Python heredoc with CJK UI string literals never executed and occupied the tool call for the full 300 s deadline. The final tool result was:

Your command timed out after 300 seconds or experienced an OOM error. The persistent bash shell was reset.

This appears to be the same failure class as #3522 (macOS persistent shell + CJK/readline) and #11085 (multiline PTY input), still present on the current Desktop build.

The user-visible symptom was especially misleading. While the parent sat on Running command, all four delegated children had already done real work and finished; the Agent Teams view showed them as idle/continuable and the task board showed 5 members / 0 tasks. It therefore looked as if the subagents were stuck, but their own sessions show execution and final output. The parent resumed immediately after the 300 s timeout result.

Timeline (Asia/Shanghai)

• Around 16:47-16:58: four delegated children completed separate work (roughly 6m46s to 10m02s each).
• 17:37:14.997: parent step 121 issued the bash call. Command shape: git apply <temp patch> && python3 - <<'PY' ... PY; the embedded Python replaced strings including 通知 未读通知.
• 17:37:15.000: the external provider log recorded client aborted mid-stream. I am not claiming this is causal; it is included only because it is the nearest timestamped transport event.
• 17:37:15-17:42:21: no output from the requested command. The input file edit did not occur.
• 17:42:21.817: the tool returned the 300 s timeout/OOM message and reset the shell.
• 17:42:21.857: parent resumed normally at step 122.

A subsequent 511-character git apply && perl -0pi ... command containing CJK succeeded, so the shell recovered after reset.

Why this is not a subagent hang in this incident

• The four children had completed before the parent's stuck tool call.
• Their sessions contain actual tool calls and final messages.
• The parent, not a child, was the only active work at the stuck point.
• The parent advanced as soon as the bash tool returned its timeout result.

The remaining UX problem is that completed children are rendered as idle/continuable and no task outcome survives in the task board, so the human cannot distinguish "children finished; parent is blocked on bash" from "children never ran". Related visibility discussion: #6216.

Reproduction

1. Use the Desktop build with the persistent bash tool and an Agent Teams session.
2. Let several delegated children finish.
3. From the parent, issue a roughly 1 KB python3 - <<'PY' command that contains CJK string literals used for a file replacement.
4. Observe that the intended edit does not run and the tool call remains active until the 300 s timeout.
5. The timeout result resets the shell; a smaller subsequent CJK command may succeed.

The exact command and event excerpt can be sanitized and provided if useful. No session log, account data, credentials, or private host details are attached.

Expected behavior

• A short CJK heredoc passed to bash should execute, or be rejected immediately with a clear input-size/locale error rather than waiting 300 s.
• The timeout should not be diagnosed as possible OOM unless OOM was actually observed (also noted in Persistent Bash timeout message should not diagnose OOM #1186 / Persistent shells blame a command deadline on a possible OOM the runtime never observed #3926).
• After a transport abort, the tool call should surface an interrupted/retryable state promptly instead of remaining visually active until the hard deadline.
• Agent Teams should retain whether a child completed, failed, or is genuinely waiting, rather than collapsing completed children to an indistinguishable idle state.

Related discussions

• terminal-bash: persistent shell stalls for the full 300 s timeout on CJK input (C-locale readline reads UTF-8 bytes as Meta bindings) #3522 - persistent shell stalls for the full 300 s timeout on CJK input
• bash tool hangs on large multiline commands (heredoc writes time out, file never created) #11085 - bash tool hangs on large multiline commands / PTY input path
• list_agents: carry a last-activity age per child — bare [running] is indistinguishable from a stalled child #6216 - bare idle is indistinguishable from a stalled child

[PerryLink]

Two of the four asks are already pinned in the source.

The 300 s result is hardcoded to mention OOM, and the code itself calls that a TODO rather than a finding: packages/shell/tool-bash-persistent/src/index.ts:360-361 has // TODO: Report a timeout only; this signal does not establish an OOM. directly above the string you quoted. So "or experienced an OOM error" is noise, not a diagnosis.

On size: the call is never sent as multiple lines. wrapCommand (:82-87) flattens it into one physical line — printf …; eval -- $'…' — and packages/terminal/terminal-bash/src/session.ts:391 appends the submit \r and writes the whole string once (:394). Nothing on that path checks the length; the only configured bound is the deadline (timeoutMs defaults to 300_000 at :461 and :470). A 970-character CJK command is roughly three times the bytes of an ASCII command of the same character count, and nothing rejects it early: it either fits through the pty write or it does not.

When it does not, the state is an unterminated $'…' rather than an unterminated heredoc — the lost tail is the one carrying the closing quote, which is why no statement runs and the file stays untouched.

The reset is real: the timeout branch calls shells.reset(...) at :358, which reaches ctx.terminals.kill (:231-234), so a smaller follow-up command succeeding afterwards is expected rather than lucky.

What I did not check: the macOS pty write itself. I read the source at 22ddee3; there is no macOS host here, so the byte threshold in your reproduction is still yours, not mine.