Bug: Subagents silently time out (600000ms) after long parent sessions — spawn never completes

[roman-ryzenadvanced]

Reporter

Discord user: TiltStable
Discord thread: https://discord.com/channels/1346756824233148527/1529813063631376404

---

Symptom

Subagents (Agent tool with subagent_type) silently time out at 600000ms (10 min) after the parent session runs for a while. No error message — ZCode just returns "Subagent was inactive for 600000ms". The per-subagent exec directory (~/.zcode/cli/exec/sess_subagent_<uuid>/) stays empty (0 bytes) — ZCode never writes the subagent stdout/stderr logs, suggesting the spawn itself does not complete.

---

Repro Steps (reproduced 3× today)

1. Start a long interactive session (~940 log lines / ~688 KB transcript, ~18 prior agent calls).
2. Dispatch any subagent (fable-judge, code-reviewer — same behavior) with any prompt (even a focused 5-question verify prompt with all files prepared locally, NO WebFetch required).
3. Result: "Subagent was inactive for 600000ms".

---

Worked Earlier in the Same ZCode Version

Same subagent (fable-judge) completed successfully earlier this week on a similar task: 335s, 49 tool uses, 718k tokens. Same ZCode version 3.4.2.3624 (installed 2026-07-21, app.asar modified 2026-07-21).

• The same subagent (code-reviewer) ran today with a tightly-scoped prompt and completed in 57s.
• With a broader prompt it hung at 600000ms.

---

What Was Ruled Out

• WebFetch / network: Removed all WebFetch from the prompt, prepared all files locally with curl → Bash → local paths. Still hangs.
• Process leak: Only 6 node.exe running, all are MCP servers (playwright, z_ai, context7 + npx wrappers), ~34 MB each, stable.
• Memory: No OOM, plenty of free RAM.
• File / network speed: curl on the same 87 KB file returns in 0.3s.

---

Hypothesis (low confidence)

Parent session context length / accumulated state affects subagent spawn. Correlation: longer parent session → higher hang rate. But this worked on similarly long sessions a few days ago, so something may have changed.

---

Environment

Detail	Value
ZCode version	3.4.2.3624 (running; app.asar modified 2026-07-21)
MCP servers	4 configured (playwright, z_ai/mcp-server, context7, serena via uvx)

---

Regards,
Roman
http://www.rommark.dev

VIbe Coders Telegram Channel: https://t.me/VibeCodePrompterSystem

[github-actions]

👋 感谢你的反馈，我们已经收到。

• 维护者会在 3 个工作日内 给出首次响应。
• 状态保持为 status: 待评估，你可以随时补充信息。
• 信息不全时我们会打上 needs: 更多信息 标签并 @ 你。

---

👋 Thanks — we've received your issue.

• A maintainer will respond within 3 business days.
• Status stays at status: 待评估 (Triage); feel free to add context.
• If we need more details, we'll add needs: 更多信息 and ping you.

[efica]

only with GLM llms its broke for me... the llm stop working past one minute ... thankyou for your work,

[TiltStable]

Wrapping up our investigation — three things worth flagging.

(1) The 650KB parent transcript theory is not the whole story in our case. After a full ZCode restart (fresh session, parent transcript = 0 bytes, clean IPC worker pool — we verified all 13 app-server --stdio workers respawn from scratch on boot, so it is not orphan pollution either), the hang still reproduces.

(2) This is a regression from our side. On the same ZCode build 3.4.2.3624, just two days earlier (2026-07-21), fable-judge successfully verified a pptx skill patch with 56 files and 12 sub-bullet assertions in a single Agent call — 335s, 49 tool uses, 718k tokens, returned PASS WITH CAVEATS. Same agent definition, same machine, same ZCode version. So whatever broke, it broke between July 21 and July 23, and it is not the prompt size: 56 files + 12 assertions used to work, now 2 files + 5 assertions hangs.

We ran a 22-test binary-search bisection on prompt structure. In our recent sessions (last 2 days) the hang reproducibly triggers when the subagent prompt combines:

• ≥2 files to read AND
• ≥5 assertions with structured (a)(b)(c)(d)(e) sub-bullets

Working in our recent sessions:

• 1 file + 4 sub-bullet assertions → 78s
• 2 files + 4 sub-bullet assertions → 100s
• 2 files + 8 assertions as a flat numbered list (no sub-bullets) → 32s

Hanging at 600s in our recent sessions:

• 2 files + 5+ sub-bullet assertions → 600s timeout
• 4 files + 5+ sub-bullet assertions → 600s timeout

Honest caveat: it is not 100% deterministic — one re-run of the same 5-assertion 2-file prompt completed in 55s while the previous attempt hung. But the pattern is consistent enough across 22 tests.

(3) Chunking workaround also fails sometimes. Even after adopting the ≤4-assertion chunking rule, a subsequent fable-judge call with a 2-file / 4-assertion / 1.2KB+30KB prompt hung at 600s. The chunking reduced the hang rate but did not eliminate it. We ended up verifying the artifact via Bash self-checks (grep/ls/wc against the harness files), which reliably covers inventory completeness, gate consistency, and path accuracy.

@efica comment above suggests it may be GLM-specific ("only with GLM llms its break for me... the llm stop working past one minute"). The regression angle seems important: if the same prompt structure worked two days ago on the same build, something server-side or model-side changed between July 21 and July 23. Can you share what shipped in that window (model version bump, serialization change, IPC buffer tweak)? Happy to share the full 22-test bisection table if useful.