cordis_inspect_query client-platform queries hang forever when no page responds, freezing the agent

[mayf3]

Summary

cordis_inspect_query with platform: "client" can hang forever (no timeout), permanently freezing the agent: the agent stays running, every later inbox message queues unprocessed, and only a manual agent.cancel() (keepInbox) unblocks it.

Repro / observed behavior

While developing a dynamic Cordis plugin, an agent called:

cordis_inspect_query { platform: "client", provider: "Service", method: "listService", input: { service: "styles" } }

The tool call never returned a tool/result. The session log ends at the tool/call event; the agent stays status: running indefinitely; subsequent send/followup messages sit in the inbox (agent/inbox/spliced appended, never claimed). This reproduced three times in a row — the agent retried the same client query after each manual cancel and hung again each time.

Root cause

• tool-cordis/src/index.ts registers cordis_inspect_query without timeoutMs.
• The client path (cordis-host-runner/src/inspect-registry.ts → queryClient) emits cordis/inspect-query and awaits a promise that only settles on resolveClientQuery (a page response) or signal abort.
• The cooperative timeout guard (dsh-tool-call-timeout-policy) only arms a deadline when the tool declares timeoutMs — so this tool has zero timeout protection.
• The tool's own description even documents this: "A Client query waits for the first valid page response and remains pending until a page answers or the Tool is cancelled."

When no browser page is attached/answering (headless-ish usage, closed tab, page crash, or a client manifest present but no live client runner), the promise never settles and the whole agent turn is wedged.

Suggested fix

1. Give cordis_inspect_query a bounded timeoutMs (e.g. 15–30s) so the cooperative guard converts a silent hang into a TOOL_TIMEOUT error result the model can see and react to.
2. Optionally, in queryClient, add a hard deadline independent of tool config, and/or detect "no live client page" early and fail fast with a clear message instead of queueing an unanswerable request.

Impact

Any agent session that queries a client platform without a responding page is permanently wedged; the user sees a "stuck" session with no error surfaced. A timeout would turn this into a recoverable tool error.

Environment

• DeepSeek Harness 0.1.0-rc.5 (source launch)
• Node 25 / macOS

[argszero]

Verified every claim against master (47f9438) — the wedge is real, and there are two details worth adding before fixing:

Source confirmation

1. cordis_inspect_query registers without timeoutMs — packages/extensions/tool-cordis/src/index.ts:61-90 (defineTool({ name: 'cordis_inspect_query', ... }), no timeoutMs field). Its own description documents the trap: "A Client query waits for the first valid page response and remains pending until a page answers or the Tool is cancelled."
2. The cooperative guard only arms declared budgets — packages/guard/timeout-policy/src/index.ts:57-59: const timeoutMs = ctx.tools.get(...)?.timeoutMs; if (timeoutMs === undefined) return next() — no declaration → no deadline, promise delegated unchanged.
3. queryClient's promise settles on exactly two paths — packages/extensions/cordis-host-runner/src/inspect-registry.ts:158-195: resolveClientQuery (a page answers) or signal abort (:171-180). With no live page, this.ctx.emit('cordis/inspect-query', request) (:190) goes nowhere and await result (:185) waits forever. Confirmed.
4. timeoutMs is a supported defineTool field — core/tools/src/index.ts:255 + schema validation :563-564 — so the fix is a one-field addition.

Systemic note: the whole tool-cordis family is unguarded

No tool registration in tool-cordis/src/index.ts declares timeoutMs (grep confirms zero). That's fine for cordis_inspect_self/list (host-side, locally bounded execution), but it means every future client-platform tool inherits the same no-deadline default — worth a convention ("client-platform tools MUST declare timeoutMs or fail fast") rather than a one-off.

Design nuance: timeout is the safety net, fail-fast is the primary fix

A plain timeoutMs (say 30 s) also cuts the legitimate slow-page case (a page that answers at 35 s), whereas the actual broken case here is no page at all (headless, closed tab, page crash). Two-layer fix:

1. Primary — fail fast on "no live client page": the registry tracks clientManifest (registered providers, :49/:84) but not live attachment. Add a live-attachment counter — the client runner half increments on connect/decrements on disconnect — and queryClient throws immediately (clear error: "no live client page is attached to answer") when the count is zero. This turns the headless wedge into an instant, model-visible error without changing the slow-page semantics at all.
2. Safety net — timeoutMs on the tool: a generous bound (e.g. 60 s) so even a pathological page-answer path eventually degrades to a recoverable TOOL_TIMEOUT instead of an eternal wedge.

Cross-thread note

On agent.cancel(), the open turn gets repaired at the next load by interruptedTurnClosers (synthesized tool/result, TOOL_OUTCOME_UNKNOWN) — so the wedged tool call does not permanently poison the transcript (unlike the #1337 dangling-call crash path). The damage is confined to the wedge itself: running forever, inbox queueing, no error surfaced. That makes the fix purely about bounded/fail-fast resolution, which is the good news.

[Diluka]

{
  "input": {
    "service": "conversation"
  },
  "method": "listService",
  "platform": "client",
  "provider": "Service"
}

这个参数也是永久挂起