Pi subagents: permission prompts only appear in the child thread

[SpyrosPsarras]

Problem

When a Pi thread delegates a task to a Pi subagent (delegate_task) and the child hits a permission prompt, the prompt only appears in the child thread. The parent thread shows nothing, and the subagent sits waiting until someone opens the child thread and answers. If you mostly work in the main thread, a delegated task just looks stuck.

This comes up with @gotgenes/pi-permission-system, which raises an ask as an extension select dialog. T3 turns that into a user_input_request on the thread that owns the Pi process, which is the child.

Reproduction

1. Install @gotgenes/pi-permission-system 40.1.2 as a Pi package, with its default config. That config already makes opaque wrappers such as bash -c an ask.
2. In a Pi thread, have the agent call delegate_task with providerInstanceId: "pi" and a task that runs bash -c 'echo probe'.
3. Read the child thread. It has pendingRequestCount: 1, a user_input_request "Permission Required … rule: " with status waiting, and the run is running.
4. Read the parent thread. It has pendingRequestCount: 0 and no prompt, and the task stays working with no sign that it needs input.

Versions: T3 0.0.46-nightly.20261009.2873 (server on Linux, web client), Pi 1.1.0, pi-permission-system 40.1.2. On main at b1ec4b3 the relevant code looks unchanged.

Why it happens

pi-permission-system already supports forwarding a subagent's ask to its parent session's dialog. For a child that runs as its own pi process, it needs one env var at spawn, PI_SUBAGENT_PARENT_SESSION=<parent Pi session id> (subagent integration docs). The parent session serves the forwarded requests and answers them in its own dialog.

T3 builds each Pi child's environment in buildPiRpcLaunch from the provider's own environment and never names a parent. The child therefore thinks it is a top-level interactive session and prompts locally.

Possible directions

These are options for a maintainer to choose from, not an implementation I'm asking you to take:

1. Pi-specific, small. When T3 launches a delegated Pi child under a Pi parent, set PI_SUBAGENT_PARENT_SESSION to the parent thread's Pi session id. Permission prompts then show up in the parent thread, where pi-permission-system already serves them, and the child resumes once the parent answers. It relies only on that package's documented convention, and nothing changes for users who don't install it.
2. Provider-independent. Show a delegated child's pending approval and input requests in the parent thread or the subagent row, so you can see and answer them from there. This would cover every provider, not only Pi with this package, but it changes the product more.

Is either direction something you'd accept? If you prefer option 1, I can open a focused PR with a test for the launch environment.

What I couldn't check: whether the parent's prompt shows up while the parent has no active turn (for example, when it ended its turn waiting for the task notification). The trace above shows the prompt is never forwarded in the first place.

Investigated and drafted by Claude Opus 5.5 in the Pi harness inside T3 Code, posted from @SpyrosPsarras's account at his request.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Thanks for the detailed trace. The core problem here, a delegated child blocking on an approval or question while the parent shows nothing, is already tracked in #15082, so I'm closing this as a duplicate to keep the discussion in one place.

• [Bug]: A delegated task that asks a question or needs approval never tells its parent (V2) #15082 is the canonical report (provider-independent, your option 2).
• fix(server): tell parents when a delegated task is waiting for input #13343 proposes the server-side fix: queue a notice on the parent when a delegated child has a pending request.
• fix(chat): surface pending subagent questions on parents #16634 surfaces pending subagent questions on the parent row in web and mobile.
• Expose thread lineage to delegated children in the launch env (T3_THREAD_KIND / T3_PARENT_THREAD_ID / T3_TASK_ID) #12286 covers exposing parent/child lineage in a delegated child's launch environment, which is the closest existing thread to your Pi-specific option 1 (PI_SUBAGENT_PARENT_SESSION).

If you want to push the Pi-specific env var, adding that detail (and the pi-permission-system docs link) as a comment on #15082 or #12286 is the best place for it.