Confirmed behavior
A supervised agent session can remain alive and actively work without writing to its PTY for an extended period. The session host then reports activity: idle and may report zero scrollback even though the CLI is consuming CPU/network resources and updating its own transcript or state.
This is not a general PTY-capture failure: a disposable shell session that printed a marker was captured correctly. The problem is that PTY output is currently the only activity signal for silent, long-running CLI agents.
Why it matters
Operators and the harness cannot distinguish:
- an agent that is legitimately thinking, waiting on a provider, or doing silent work;
- an agent that is hung before producing output; and
- an agent whose output is being recorded outside the PTY.
Marking all such sessions as idle makes the Work UI and automated timeout decisions misleading.
Reproduction
- Run
agent-harness serve with a valid session host and a CLI agent command that can work silently for several minutes.
- Start a project item.
- Observe the session through the session-host API while the CLI process remains alive and its external transcript/state advances.
- The session reports
activity: idle (often with scrollback_bytes: 0) despite the process doing work.
The issue is independent of repository, language, workload, and model provider.
Expected behavior
Expose enough information to distinguish silent activity from a genuine hang. Possible signals include process liveness/resource activity, a heartbeat emitted by the agent wrapper, transcript/file activity supplied by the command adapter, or an explicit activity: working-silently state. The design must remain provider-neutral and must not treat process liveness alone as proof of useful progress.
Timeouts should be based on a documented combination of signals and should preserve actionable diagnostics.
Acceptance
Add an integration test with a deterministic fake agent that stays alive, produces no PTY output, and updates a separate progress signal. Verify that the API/UI distinguishes it from a no-progress hang, while a truly stuck process still reaches the configured diagnostic timeout. Document the signal contract for hosted CLI agents.
Confirmed behavior
A supervised agent session can remain alive and actively work without writing to its PTY for an extended period. The session host then reports
activity: idleand may report zero scrollback even though the CLI is consuming CPU/network resources and updating its own transcript or state.This is not a general PTY-capture failure: a disposable shell session that printed a marker was captured correctly. The problem is that PTY output is currently the only activity signal for silent, long-running CLI agents.
Why it matters
Operators and the harness cannot distinguish:
Marking all such sessions as idle makes the Work UI and automated timeout decisions misleading.
Reproduction
agent-harness servewith a valid session host and a CLI agent command that can work silently for several minutes.activity: idle(often withscrollback_bytes: 0) despite the process doing work.The issue is independent of repository, language, workload, and model provider.
Expected behavior
Expose enough information to distinguish silent activity from a genuine hang. Possible signals include process liveness/resource activity, a heartbeat emitted by the agent wrapper, transcript/file activity supplied by the command adapter, or an explicit
activity: working-silentlystate. The design must remain provider-neutral and must not treat process liveness alone as proof of useful progress.Timeouts should be based on a documented combination of signals and should preserve actionable diagnostics.
Acceptance
Add an integration test with a deterministic fake agent that stays alive, produces no PTY output, and updates a separate progress signal. Verify that the API/UI distinguishes it from a no-progress hang, while a truly stuck process still reaches the configured diagnostic timeout. Document the signal contract for hosted CLI agents.