Summary
The built-in agent can get stuck in an indefinite wait_for loop when a pane is running an interactive agent-CLI (Claude Code / Codex / OpenCode). It polls the pane waiting for it to "settle", but those TUIs never return to a settled shell prompt, so the agent loops for many minutes with no progress (heading toward max_turns), and the agent panel appears frozen/hung. Separately, the tab-labeling model fires far too often against a pane whose output keeps changing.
Environment
- con
0.1.0 (build 85), macOS, embedded Ghostty, agent model GLM-5.1.
Observed (from RUST_LOG=info,con_agent=debug,rig=debug)
A single agent run (request_start … system_chars:35595, user_chars:8) targeted a pane that was running an interactive Claude Code session, then:
seq 3 wait_for(pane_id:0, pattern:"⏺")
seq 5 wait_for(pane_id:0, pattern:"⏺")
seq 7 wait_for(pane_id:0, pattern:"Ideating")
seq 9..31 wait_for(pane_id:0) # ~16 repeats, pattern:None
… elapsed_ms climbs 493,518 → 594,927 (~10 minutes, no progress)
seq 32 send_keys(pane_id:0, "\x1b") # ESC, trying to break out
The patterns ⏺ and Ideating are the other agent-CLI's own UI markers — i.e. the agent recognized it was watching a coding-CLI TUI but still hand-rolled a read_pane + wait_for poll loop instead of treating it as a settled-never target.
Notably, con already ships a LOCAL_AGENT_CLI_WORK playbook and an agent_cli_turn / ensure_local_agent_target tool path intended for exactly this ("so con can wait for the CLI to settle"), but the model ignored it and looped on raw wait_for.
Suggested fixes
wait_for no-progress guard. Track the pane's output across consecutive wait_for calls; after N (e.g. 2–3) calls on the same pane with no meaningful delta, return a terminal "no progress — stopping" result so the model breaks the loop instead of re-issuing wait_for.- Enforce the agent-CLI playbook, don't just advise it. When a pane is detected as an interactive agent-CLI, steer the tool layer away from raw
wait_for-until-settled (or make wait_for on such a pane short-circuit) and route toward agent_cli_turn. Advisory prompt text alone did not prevent the loop here.
- Throttle the tab-labeler. In the same window the tab-labeling agent fired roughly every 6 seconds continuously (≈130 calls vs ≈84 for the main agent) because the target pane's output kept changing. Debounce / rate-limit per tab, and skip re-labeling when only volatile output (not cwd/command) changed.
Impact
On a pane running another agent CLI, the panel hangs for minutes with a spinning activity section and no output — indistinguishable from a crash to the user. A wait_for no-progress cap (1) would also bound several other "agent waits forever" failure modes generically.
Found via a hands-on log capture against a running con instance. Happy to share more of the (sanitized) flow log or test a patch.
Summary
The built-in agent can get stuck in an indefinite
wait_forloop when a pane is running an interactive agent-CLI (Claude Code / Codex / OpenCode). It polls the pane waiting for it to "settle", but those TUIs never return to a settled shell prompt, so the agent loops for many minutes with no progress (heading towardmax_turns), and the agent panel appears frozen/hung. Separately, the tab-labeling model fires far too often against a pane whose output keeps changing.Environment
0.1.0(build 85), macOS, embedded Ghostty, agent model GLM-5.1.Observed (from
RUST_LOG=info,con_agent=debug,rig=debug)A single agent run (
request_start … system_chars:35595, user_chars:8) targeted a pane that was running an interactive Claude Code session, then:The patterns
⏺andIdeatingare the other agent-CLI's own UI markers — i.e. the agent recognized it was watching a coding-CLI TUI but still hand-rolled aread_pane+wait_forpoll loop instead of treating it as a settled-never target.Notably, con already ships a
LOCAL_AGENT_CLI_WORKplaybook and anagent_cli_turn/ensure_local_agent_targettool path intended for exactly this ("so con can wait for the CLI to settle"), but the model ignored it and looped on rawwait_for.Suggested fixes
wait_forno-progress guard. Track the pane's output across consecutivewait_forcalls; after N (e.g. 2–3) calls on the same pane with no meaningful delta, return a terminal "no progress — stopping" result so the model breaks the loop instead of re-issuingwait_for.wait_for-until-settled (or makewait_foron such a pane short-circuit) and route towardagent_cli_turn. Advisory prompt text alone did not prevent the loop here.Impact
On a pane running another agent CLI, the panel hangs for minutes with a spinning activity section and no output — indistinguishable from a crash to the user. A
wait_forno-progress cap (1) would also bound several other "agent waits forever" failure modes generically.Found via a hands-on log capture against a running con instance. Happy to share more of the (sanitized) flow log or test a patch.