Interactive-mode tool calls have no automatic timeout — a hung command blocks the session forever

[ywg663]

Describe the bug

In interactive mode, a tool call that never returns blocks the session indefinitely. Observed case: a %%bash cell running a Node script that calls chromium.launch() through the built-in Playwright driver hung for 31 minutes with no output and no auto-abort (BrowserType.launch's own 30s timeout never fired because the hang occurred earlier in the driver handshake). The only escape was a manual Ctrl+C, which correctly surfaced as "Request was aborted".

Environment

• prime-agent 0.7.3
• Interactive mode, builtin ipython tool
• Linux, Node 22

Expected behavior

A configurable per-tool-call wall-clock timeout for interactive mode (CLI flag such as --tool-timeout-ms, or a settings.json entry, default ~5-10 min). On expiry the runtime should kill the underlying subprocess and return an isError toolResult so the agent can react (report/retry) instead of blocking the conversation with no path forward.

Current behavior

Timeout/abort machinery exists only in autonomous mode (--autonomous-timeout-ms default 1800000, --autonomous-gate-timeout-ms default 300000). Interactive mode has no tool-level timeout at all; the only builtin tool is ipython, whose %%bash/subprocess execution waits forever. User must notice and manually interrupt.

Suggested fix

Wrap interactive tool execution in a wall-clock watchdog that mirrors the autonomous wall-clock limit: kill the kernel-side subprocess group and return an abort error to the model, preserving the existing "Request was aborted" cancellation plumbing already proven in the codebase.

[ywg663]

补充一点核心诉求（维护者视角的 root cause）：

问题的本质不是"命令会卡"，而是"卡的时候用户和 agent 完全失明"。 一个工具的执行过程必须：

1. 可见 — 运行中的命令应有心跳/最后活动时间/产出迹象；31 分钟里 UI 完全静止，用户无法区分"还在正常跑"和"已经死锁"；
2. 可中断且可感知 — 超时应可配置，到了阈值自动终止并返回 isError toolResult，让模型能自主应对（重试/换方案/报告），而不是依赖人眼盯屏幕手动 Ctrl+C；
3. 兜底 — 即便不设超时，长任务也应周期性输出状态行，让"静默"与"忙碌"可分辨。

对 agent 工具类产品，无限静默挂起 = 把故障成本转嫁给用户：既占住对话，又没有信息让上层模型决策。建议至少在交互模式提供：可配置 tool timeout（默认 ~5-10min，自动 kill 子进程组 + 返回 abort 错误），以及运行中命令的心跳/进度暴露。

[Atroci]

This is the primary upstream match for the Python failure I was investigating. The visible Orca daemon-reconnect error appears to be a downstream symptom of an interactive ipython call that did not reach a terminal tool result.

Additional sanitized integration context:

• Orca 1.4.183 on Fedora Linux x86_64
• Prime Agent 0.7.3
• Node.js 24.15.0
• The affected session was running Prime as an Orca-supported/resumable agent

The v0.7.3 source confirms the timeout gap:

• ExecuteOptions exposes an AbortSignal, output callbacks, and output limits, but no wall-clock deadline.
• executeInner awaits the kernel result promise until an execution reply or an external abort; it has no per-cell timeout.
• ipython.ts passes the session signal through but does not add a tool deadline.

So a blocked Python/%%bash cell can hold the interactive turn indefinitely, leaving the client apparently waiting and making later daemon/reconnect failures much harder to distinguish from the original hung tool. The PermissionError visible in my capture was not itself the timeout; the priority is the missing terminal outcome/watchdog for the Python tool call.

The fix should preserve the existing uncertain-side-effect boundary: configurable interactive tool timeout, visible heartbeat/last-activity state, interrupt/kill of the kernel-side process tree when safe, and an explicit isError/aborted tool result so the model and user can recover without silently retrying a possibly-started operation.