[Bug]: Pi threads never report pending background work, so a running background task looks idle

[hong-tm]

Before submitting

• I searched existing issues and did not find a duplicate. The closest ones are other providers: Muse Code background monitors aren't shown as pending work; the thread looks finished and the monitor can't be stopped #19061 (Muse) and [Bug]: Antigravity ACP background tasks are marked completed when the agent stops to wait, hiding active background tasks and dropping agent wakeups in the UI #28415 (Antigravity).
• I included enough detail to reproduce or investigate the problem.

Area

apps/server (packages/provider-pi, makePiAdapterV2)

Steps to reproduce

1. Run a Pi-driver thread on an agent that supports background work. I use OmO, which runs on the Pi RPC protocol.
2. Have the agent start a background task, then end its turn while the task is still running.
3. Look at the thread while the task runs.
4. Wait for the task to finish.

I found this from recurring use, the T3 database and the bundled server source. I did not record a dedicated minimal reproduction.

Expected behavior

While the task runs, the thread shows pending background work, as Claude threads do through pendingBackgroundTasks. The thread does not settle until that work finishes.

Actual behavior

The thread looks idle or finished, the same as an agent that has really stopped. When the task finishes, the completion wake arrives and the agent resumes.

Wakes do work. In the past week, Pi-driver threads received 341 "Background task completed." continuations. Only the in-progress state is missing.

Evidence

• In the bundled source for this version, the Pi adapter sets pendingBackgroundTasks only to [], when it creates a provider thread and when it forks one. It never fills the roster.
• hasPendingBackgroundWork in that adapter only checks whether a wake is already in progress (pendingWake !== null), so it says nothing about a running task.
• In my T3 database, none of the 200 Pi-driver provider threads has a non-empty roster. Across all 65,857 rows of orchestration_events, the only events with a non-empty roster are 7 from claudeAgent. That table may not cover every thread's full history.
• I searched the OmO runtime's RPC mode for a background roster event and found none. So a fix may also need the Pi RPC side to expose one. This is an inference, and I have not checked upstream Pi.

Impact

I cannot tell "waiting on a background task" from "the agent stopped". I end up sending a nudge to threads that may only be waiting, which starts an extra turn and spends tokens. Of 16 nudges I reviewed, 5 came within about a minute of the thread going quiet.

Version or commit

T3 Code 0.1.8-nightly.20261106.4262

Environment

Linux x64, OmO 5.1.60 through the Pi driver.

Workaround

Wait for the completion wake, or read the agent's last message to see whether it said it started background work.

Investigated with an AI coding agent (Claude Code); the numbers above come from the local database and source.

[hong-tm]

Closing as a duplicate of #24187. I missed it because I searched issues only and did not search PRs. PR #24207 adds the Pi background roster that would fix the missing in-progress state I reported here. Sorry for the noise.