[oke3]

Issue for this PR

Fixes #57853

Type of change

• Test

What does this PR do?

Covers an agent file that appears after the session started, at the layer #57138 is actually about.

The subagent tests inject agents straight into the location's Agent.Service, so the config agent plugin never runs against a session's location. This case creates a session in a temp project with an empty .opencode/agents/, writes tester.md afterwards, and asserts that the location's agent catalog sees it (mode: subagent) and that subagent({ agent: "tester" }) runs it to completion.

It passes on dev: the chain session → location → config agent plugin → watcher → agent catalog → subagent tool → child session works for an agent that appears mid-session. So this is a guard, not a fix — it fails if that ever stops being true.

Why it passes, given the report in #57138: the bug was fixed by #57416 (keep locations with running sessions or background jobs), merged 2026-10-20 — one day after the reproduction on 86ac38a (2026-10-19) that was posted there. Before that fix, a location whose TTL expired could be invalidated while a session was waiting on a question or had a background job (neither is in execution.active), so the session's agent catalog went stale and subagent answered Unknown agent: tester.

How did you verify your code works?

bun test test/tool-subagent.test.ts from packages/core — 12 pass, 0 fail.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[opencode-agent]

The test does what it says. It uses the real plugin supervisor, and tester.md reaches the catalog only through the config watcher and reload. To confirm, I disabled the agent plugin's reload in src/config/plugin/agent.ts, and the new case failed. With the change, bun test test/tool-subagent.test.ts passes (12/12, and the new case passed 5 times in a row at ~0.5s), and bun run typecheck passes in packages/core.

The public API is unchanged; only a test file changes.

One thing worth fixing: when the reload is broken, the test fails at bun's 5s per-test timeout instead of at an assertion (see inline).

Related: #57138

[opencode-agent]

This loop never fails by itself, and 100 × 50ms equals bun's default 5000ms test timeout. When I turned off the agent plugin's reload, the test ended as (fail) … [5000.03ms], a bare timeout, and never got to the assertions below. A bounded wait that fails clearly would be easier to diagnose, for example locationAgents.get(id).pipe(Effect.repeat({ until: (agent) => agent !== undefined, schedule: Schedule.spaced("50 millis") }), Effect.timeout("2 seconds")). The pendingBackground wait earlier in this file does something similar.

[oke3]

Answering the question in the review — "if your test passes on current dev, either the bug has been fixed since then, or the test doesn't go through the same path as the real CLI".

It was fixed, the day after the reproduction in #57138. The bot's repro there was on 86ac38a (2026-10-19); #57416 (fix(core): keep locations with running sessions or background jobs) merged 2026-10-20, and 86ac38a is an ancestor of it.

The mechanism fits the report exactly. Before that fix, LocationActivity computed the sessions that keep a location alive from execution.active only. A session waiting on a question, in a long tool call, or with a background job emits no durable activity, so it was not in that set — and the location could be invalidated underneath it. The location's agent catalog was detached with it, and the running session's subagent answered Unknown agent: tester. After the fix, background jobs count as owners too, and the location stays alive for as long as the session needs it.

Two other things I checked while narrowing it, so the record is complete:

• The catalog itself reloads correctly on the released build: an agent created after the location was first loaded appears within a few seconds through GET /api/agent?location[directory]=…, and so does an edit to an existing agent.
• The v1 line still has the behaviour: on 1.19.3, an agent file created after the server started is never discovered (nor is an edit), there is no rescan command, and a restart picks it up. That is the version the original report ran.

I've also taken the review's other point: the wait budget now leaves the failure on the assertion rather than on bun's per-test timeout, and the case carries a 30 s timeout of its own so a loaded machine cannot trip it.