Subagents requiring approval to run command pop-up does not consistently display on initial ask

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #22361
• #23324

Powered by Codex Action

This feels like the app is treating subagent approval as thread-local UI state instead of root-session state.

The thing I would want persisted is not only "show popup" but a root-visible pending-approval record with child id, requested capability, age, and whether the request blocks only the child or the full run. Once that exists, the popup becomes just one renderer of the same state, and sidebars, notifications, and fleet-style views can all stay honest.

Without a shared pending-approval record, hidden-child approvals are hard to eliminate because every surface has to rediscover them separately.

This is super annoying, specially when I run multiple projects at once each with 2-6 agents running. Constantly wasting time on requests that never surface until I click into each agent to check

I’m seeing what appears to be the same behavior: when a main agent thread is open and a subagent requests command approval, the approval UI does not reliably appear. In practice, the workflow can look idle/stalled until I manually open the subagent’s thread and notice the pending approval there.

Expected: approval prompts from subagents should surface reliably without requiring the user to manually inspect each subagent thread.

I don’t have the exact Codex app version/platform details in this relayed report, but the behavior matches the issue description closely.

I would frame this as a root-session visibility problem, not just a popup reliability problem.

A subagent can own the proposed command, but the parent session owns the user's attention. If the request only renders inside the child thread, the run can look idle while authority is actually blocked somewhere else.

The object I would want persisted is a root-visible pending approval record with:

• root session id;
• child agent id;
• child thread id;
• command or tool summary;
• requested capability;
• created_at and age;
• blocking scope, such as child-only or whole-run;
• terminal state: pending, approved, denied, expired, or cancelled;
• renderer acknowledgements for popup, sidebar, badge, mobile, and desktop surfaces.

Then the popup is only one projection of the same state. The root thread, sidebar, dock badge, mobile view, and child thread should all read from that record. If the popup renderer misses the first attempt, the request is still visible and actionable elsewhere.

Regression cases I would pin:

1. child agent requests command approval while the parent thread is open, and the root surface shows a pending approval;
2. popup render fails or is dismissed, but root/sidebar pending state remains visible;
3. two child agents request approvals at the same time, and the records cannot collide;
4. approving from the root surface resumes the correct child agent and command only;
5. stale or expired approval leaves a terminal state instead of making the run appear idle;
6. mobile or desktop reconnect rehydrates pending approval state before showing the run as idle.

That makes hidden approvals much easier to eliminate: visibility becomes a session-level contract, not a best-effort popup.

Plz fix this, super annoying