job_output/job_kill with a live continuable subagent id throws the same raw unknown job <uuid>` as a fabricated id

[Danceiny]

@/tmp/194-body.md

[argszero]

Confirmed on c291e7961a, and it is a diagnosability gap rather than a lookup bug — the two id namespaces are genuinely different, and nothing at the call site says so.

Why the failure is identical. The subagent tool has two async shapes:

how it was asked	what comes back	how it is driven
run_in_background: true (one-shot)	{ kind: 'background', jobId } (tool-subagent/src/index.ts:560)	job_output / job_kill
continuable background delegation	{ kind: 'continuable', subagentId } (tool-subagent/src/index.ts:536)	send_message / interrupt_agent

A continuable delegation registers no job at all — continuation.ts:108 mints the child id itself and the continuation manager holds the AgentHandle directly. So the id never reaches the registry, and jobs-local/src/index.ts:347 throws for it with exactly the same words it uses for a fabricated id:

if (job === undefined) throw new Error(`unknown job ${id}`)

Job ids are minted as JobId(`${spec.kind}-${count}`) (jobs-local/src/index.ts:151-153) — <kind>-<counter>, counter from 1, kinds are lowercase words (bash, pwsh, subagent, pty-send). A continuable subagent id is a bare uuid, so it was never minted by the registry. The message cannot distinguish the two cases, and the model re-tries the control instead of switching tools.

A guard plugin for this is published: @argszero/cordis-plugin-job-id-guidance (repo).

dsh plugin add @argszero/cordis-plugin-job-id-guidance

It watches the tools/post-execute seam and appends one pointing sentence to that exact failure, keeping the authoritative text first:

Error: unknown job 3e9f0a1b-4c2d-4e6f-8a90-1234567890ab

That id is not one of your background job ids — those look like bash-1. job_list shows the job ids you can read. If this id came from subagent, it is a durable subagent id rather than a job; drive it with send_message / interrupt_agent.

Three deliberate limits, since a wrong diagnostic is worse than none: it fires only for this call's own failure (the id is matched with a trailing boundary, so bash-12 cannot answer for bash-1); it stays silent for any id shaped like a job id (subagent-in-process-driver mints child ids as bare uuids, so a live continuable id is not resolvable through listChildren, and a positive "this is a subagent id" claim could be false); and it never vetoes a call, rewrites a success, or turns its own error into a second failure.

The durable fix belongs in core rather than a plugin, and the cheapest form is at the write boundary: jobs-local's unknown job ${id} is the only place that knows the id came from the wrong namespace, and it could name the tools that do accept a non-job id. Until then the plugin covers the model-facing half.

One note for the maintainers: the body of this discussion resolved to the literal text @/tmp/194-body.md, so only the title is readable — the detail above is reconstructed from the title and the code.

That is reproducible, and it is a CLI footgun worth knowing about, because it silently eats long bodies: gh api expands @file only for -F/--field (typed), never for -f/--raw-field (raw string). Posting a comment with -f body=@notes.md sends the six-character path instead of the file, with no error. If any submission path in this repo's tooling uses the lowercase flag, its comment bodies are being stored as paths. I hit it myself one comment ago and had to updateDiscussionComment to repair it.

[Moody-Sin]

Confirming @argszero's diagnosis from a production run, and adding the half that makes it more than a diagnosability gap: the missing collector is what pushes the parent into sleep polling — and that sleep then delays the very settlement notice the parent is waiting for.

What I hit. Parent session, Agent Teams enabled, parent delegated via subagent with the default run_in_background: true (continuable), so it got back exactly the shape described above:

dispatch: {"kind":"continuable","subagentId":"<childId>"}

With only a subagentId in hand, both collectors are dead ends:

• job_output → unknown job (this thread), and
• wait_agent → guaranteed noProgress. Its guard only inspects ctx.agentTeams.listMembers(caller) (dsh-experimental-tool-agent-team), while @deepseek-ai/dsh-subagent never touches agentTeams (grep agentTeams → no hits). A continuable child is never registered as a team member, so the one tool described as "Wait for the next teammate status…" cannot see subagents at all.

So the only remaining move is sleep. In the run I measured: 44 sleep calls inside a single turn, 180–480s each, 16,320s ≈ 4.53 hours of the parent doing nothing. That is not the model being lazy — it is the model having no other legal move.

And the workaround is self-defeating. While the parent sits inside a long blocking tool call, the child's settlement goes out through notifySettlement:

this.sendWaking(parent, message, parent.status === "idle" ? "queue" : "steer");

steer lands in next-step, which the loop only consumes at a step boundary (dsh-agent-loop: steer(input) { this.send(input, "next-step", true); }). A 300s sleep pushes that boundary 300s out, so the notice is delayed by precisely the sleep that was meant to await it. Measured single instance: the child settled and wrote agent/inbox/spliced at 21:51:22; the parent consumed it at 21:54:09 — 2m47s late, purely because it was sleeping.

Relation to the other threads. This is the same notifySettlement path as #7508 (which asks for the opposite: an opt-out to silence the notice) and the missing primitive raised in #684. Both requests are real — one notifySettlement, pulled in two directions.

Suggestion. Cheapest fix that removes the dead end: let job_output accept a subagentId, or give continuable children a wait/poll handle. Failing that, the tool description should state outright that a continuable background child has no collector, and that run_in_background: false is the only way to await it.