Summary

background_output(task_id=...) can keep reporting a background task as running even after the delegated session has already finished and is fully readable via session_info / session_read.

This creates a stale-status mismatch in the orchestrator layer:

• background_output says the task is still running
• session_info shows the session ended
• session_read returns the final assistant synthesis/output

In practice, this makes it look like the agent is unfinished unless you manually inspect the returned session_id.

Why this matters

For delegated/background-agent workflows, background_output is the obvious status/result retrieval API. If it reports running after the session is actually complete, orchestrators can:

• wait unnecessarily
• miss finished work
• distrust the background task status signal
• end up using session_info / session_read as the real source of truth

Environment

• Project: business-brain
• Date observed: 2026-03-08
• OpenCode plugin in use: oh-my-opencode / oh-my-openagent stack
• Local model/runtime notes from project context:
  • OpenCode with background delegated agents
  • multiple background tasks launched in parallel via task(run_in_background=true, ...)

I can provide more env/version details if needed, but this looks like a task-state synchronization issue rather than a model-specific issue.

Observed behavior

I launched several background tasks. The tool responses returned both background_task_id and session_id metadata.

Example launched tasks:

• bg_bca67583 → session ses_33231cb66ffeRu57B7Nocl5zEd
• bg_70336091 → session ses_33231cb49ffe1VPkxaT4SC9WfU
• bg_b6ff645d → session ses_3323142fbffeKIzegAKgtyA4zW
• bg_654e9f75 → session ses_33230cd67ffeDpfUV2alGzEhAU
• bg_2ccff1e8 → session ses_33230a8dbffeQpA7o5wi0HKbyL

Then I queried background_output(..., block=true, timeout=300) for those task IDs.

background_output said they were still running

For example, it returned output like:

# Task Status
| Field | Value |
| Task ID | `bg_bca67583` |
| Status | **running** |
...
> Timed out waiting after 300ms. Task is still running; showing latest available output.

This happened for all five tasks above.

But the sessions were already complete

Immediately afterward, session_info(session_id=...) showed the delegated sessions had already ended and had real message histories:

• ses_33231cb66ffeRu57B7Nocl5zEd
  • Messages: 9
  • Date Range: 2026-03-08T14:16:09.117Z to 2026-03-08T14:19:24.846Z
• ses_33231cb49ffe1VPkxaT4SC9WfU
  • Messages: 4
  • Date Range: 2026-03-08T14:16:09.145Z to 2026-03-08T14:16:31.259Z
• ses_3323142fbffeKIzegAKgtyA4zW
  • Messages: 13
  • Date Range: 2026-03-08T14:16:44.037Z to 2026-03-08T14:18:21.245Z
• ses_33230cd67ffeDpfUV2alGzEhAU
  • Messages: 10
  • Date Range: 2026-03-08T14:17:14.137Z to 2026-03-08T14:18:05.685Z
• ses_33230a8dbffeQpA7o5wi0HKbyL
  • Messages: 10
  • Date Range: 2026-03-08T14:17:23.493Z to 2026-03-08T14:19:13.781Z

And session_read(session_id=...) returned the final synthesized outputs, including long-form final answers from the delegated agents.

Concrete example

For session ses_3323142fbffeKIzegAKgtyA4zW, session_read returned a completed final report ending with:

## n8n Automation Inspection Report
...
### Recommended Next Steps
1. Immediate: Either disable `Order Creation` workflow...
2. Investigate: Restore n8n-mcp access...
...

So from the session layer, the work was clearly done.

Expected behavior

One of these should be true:

1. background_output(task_id=...) should switch from running to a completed state once the delegated session has finished, OR
2. if task completion is intentionally decoupled from session completion, the API/docs should clearly explain why a task can remain running after the session is done and how callers should retrieve results reliably.

Actual behavior

background_output appears to lag or get stuck on running, while session_info / session_read already expose the completed session and final output.

Reproduction pattern

I haven't reduced this to the smallest possible repro yet, but the observed pattern is:

1. Launch several background delegated tasks with task(run_in_background=true, ...)
2. Capture both background_task_id and session_id
3. Wait until enough time has passed that the delegates should be done
4. Call background_output(task_id=..., block=true, timeout=300)
5. Observe running
6. Call session_info(session_id=...) and session_read(session_id=...)
7. Observe completed session with final assistant output already present

This happened across multiple tasks in the same parent session, so it does not look like a one-off task failure.

Suspected issue

My guess is the background task state machine and the delegated session lifecycle are not fully synchronized. The session may be finalized, but the background-task registry/status that powers background_output is not being marked complete promptly (or at all).

Current workaround

Use session_info(session_id) / session_read(session_id) as the real source of truth once you have the session_id from the original task() response.

That works, but it undermines background_output as the canonical result retrieval path.

Possible fixes

• Ensure background task completion is updated when the delegated session writes its terminal assistant message / exits
• Make background_output consult session terminal state if a session_id exists
• Document the intended relationship between background_task_id and session_id
• Consider returning a hint in background_output when the linked session is already complete

If helpful, I can also file a follow-up issue with a minimized reproduction that uses a tiny background task and captures both tool outputs side-by-side.