Title: Agent self-hang via foreground until-loop blocks dispatch indefinitely (recurring)

[RayKuo-Mantis]

Description

Summary

On 2026-05-13 my self-hosted OpenAB instance (claude-agent-acp) hung three times in one day because the Claude agent self-spawned until ... grep -q "X" log ; do sleep 30; done Bash tools where the grep keyword never matched. Each hang blocked the entire Discord dispatch queue for 1-3 hours until I manually docker exec kill the stuck PID inside the container.

This is orthogonal to PR #791 (gateway reconnect) — the Discord connection is healthy throughout; the agent itself is stuck in a Bash subprocess that never returns to the ACP layer.

Repro

# In any active Discord thread with claude-agent-acp:
# Ask Claude to run any long-poll without timeout:
"執行: until false; do sleep 30; done"
# OpenAB will hang forever, queue subsequent messages with wait_ms growing unboundedly

Observed today

Time	Until-loop target keyword	Why it never matched
14:02	"summary table"	Actual log string was "Multi-turn chain summary"
15:19	===== done|watchdog	Sim was watchdog-killed mid-run, done marker never written
15:42	===== done|fail (chained 2x)	Same as above

Pattern: agent writes brittle keyword-based wait without max-iteration timeout. When keyword never appears (typo / runner kill / log format drift), Bash subprocess sleeps forever, ACP dispatch tool blocks, subsequent Discord messages queue silently.

Proposed feature: agent_dispatch_timeout_ms

Add config (config.toml [agent] or env var):

[agent]
dispatch_timeout_ms = 1800000  # 30 min default, 0 = unlimited (current behavior)

When a single dispatch exceeds the timeout:

1. Kill the agent process / send SIGTERM to claude-agent-acp
2. Post Discord reply: ⚠️ Previous turn timed out after ${minutes}m. Session reset, please retry.
3. Optionally: reset session pool so next message starts fresh
4. Log WARN openab::dispatch: agent timeout with thread_key + elapsed + last seen activity

Lower-priority companion features

• When wait_ms of pending message > threshold (e.g. 5 min), send a passive 🕒 reaction or 1-line "still on previous turn, X messages queued" so user knows it's not silently dead
• Per-thread queue depth in metrics

Severity

Lower than PR #791 (network drops more frequent than agent self-hangs in normal use), but higher than expected: I hit this 3× in 6 hours today, all without my agent doing anything malicious — just routine until ... grep ... patterns that broke when log format / sim outcome diverged from agent's assumption.

Saved logs / repro available if useful.

Steps to Reproduce

# In any active Discord thread with claude-agent-acp:
# Ask Claude to run any long-poll without timeout:
"執行: until false; do sleep 30; done"
# OpenAB will hang forever, queue subsequent messages with wait_ms growing unboundedly

Expected Behavior

normal conversation.

Environment

No response

Screenshots / Logs

No response

[CHC-Agent]

Issue at a Glance

Discord msg → Dispatcher → ACP prompt → Bash tool (until-loop)
                  │                            │
                  │ blocked                    ▼
                  │◄──────────── never returns (grep keyword mismatch)
                  │
                  ▼
          queue grows unboundedly

Hi @RayKuo-Mantis,

Thanks for the detailed write-up with timestamps and root cause analysis.

Question: What version/commit of OpenAB were you running when these hangs occurred on 2026-05-13?

PR #760 (merged 2026-05-07, included in 0.8.3-beta.5 released 2026-05-09) added pool.prompt_hard_timeout_secs (default 1800s / 30 min) which terminates any prompt that exceeds the configured timeout — including stuck Bash subprocesses — and sends session/cancel to clean up. This mechanism likely covers your scenario.

If you're on a version older than 0.8.3-beta.5, could you upgrade and test whether the issue still reproduces? The timeout should automatically kill the hung until-loop after 30 minutes and unblock the dispatch queue.

If the issue persists on 0.8.3-beta.5+, that would indicate the existing timeout isn't reaching the Bash subprocess layer, and the additional agent_dispatch_timeout_ms you proposed would be needed as a separate safeguard.

Also, if you can reproduce this again, it would help to have a more complete repro flow — e.g. the exact prompt/message that triggered the agent to spawn the until-loop, your config.toml relevant sections, and container logs showing the hang timeline. The current repro (until false; do sleep 30; done) demonstrates the concept but isn't something the agent would self-generate in normal use.

Related:

• PR fix(acp): clean up pending + cancel agent on abandoned prompts #760 by @brettchien — MERGED (0.8.3-beta.5): prompt hard timeout + liveness check + abandon/cancel
• PR fix(acp): close notify channel on EOF to prevent stream hang #470 by @masami-agent — MERGED: 10-min rx.recv() timeout as defense-in-depth
• PR fix: reconnect Discord gateway on silent WS disconnect #791 by @chaodu-agent — OPEN: gateway reconnect (orthogonal)

[chaodu-agent]

Thanks for the detailed write-up @RayKuo-Mantis.

We agree this is a valid concern — when an agent spawns an infinite bash loop without timeout, the synchronous dispatch pipeline blocks and there's no way for the user to /cancel since that message also queues behind the stuck dispatch.

Recommended workaround for now:

Add a constraint in your agent's system prompt or CLAUDE.md:

All bash polling loops MUST include a max iteration count or timeout (e.g. timeout 300 bash -c '...'). Never use unbounded until loops.

This should prevent the agent from writing infinite loops in the first place.

On dispatch_timeout_ms:

The feature makes sense as a safety net for cases where the agent ignores prompt constraints. We're keeping this at p2 — currently we only have one report and the use case (agent polling log files with until loops) is a power-user edge case.

We'll bump priority when this gets 10+ upvotes from the community, indicating broader demand. In the meantime, the prompt-level constraint should be an effective mitigation.

👍 this issue if you've hit the same problem.