Delegated sub-agent permission requests are invisible: no badge, no pet-panel row, no log line — the delegation silently stalls forever

[Charlie-1909]

Environment: Codeg v0.24.0 (latest release at time of report), Windows 11, delegation depth 1, agents: Claude Code (parent) → Grok / Codex (sub-agents).

Diagnosed by: investigated and written by Claude Code running as the active agent inside a Codeg session, at the human user's request. Findings below come from reading Codeg's own source and the app's runtime logs, not from guessing at the UI.

Symptom

A sub-agent launched through delegate_to_agent hits a tool permission prompt and stops. Nothing anywhere indicates it is waiting. The parent agent sees a delegation that never returns; get_delegation_status keeps reporting it as in-flight, because "running" and "blocked on a permission prompt" are the same state to it.

Observed concretely: a delegated Grok sub-agent sat blocked on a single permission prompt for ~20 minutes. It was found only by manually expanding the delegation card in the parent's transcript. No sound, no badge, no counter, nothing in the logs.

This is a real dead end for unattended or long-running multi-agent workflows: the orchestrating agent cannot detect the condition, and the human has no signal to react to either.

Why nothing shows up — three independent paths, all closed

1. Inline routing to the parent's tool card is not implemented. src/contexts/delegation-context.tsx:

   * Inline permission routing (child's permission_request surfaced on parent's ToolCallBlock) is deferred — the existing permission store is per-connection and would require a broader reducer change.

2. The child connection is deliberately hidden from every user-facing list. src/contexts/acp-connections-context.tsx:

   * as real connections so the child's live message, tool calls, and permission requests reach the UI, but they MUST be hidden from any user-facing connection list / picker

3. The pet panel and its badge explicitly exclude delegation children. src-tauri/src/commands/pet.rs, pet_list_active_sessions_core:

   Delegation sub-agent sessions (child conversations, i.e. parent_id set) are excluded: they are surfaced inline inside the parent's transcript, not as standalone user-facing sessions, so they must not inflate the sprite badge count or appear in the panel list.

   The test pet_list_active_sessions_excludes_delegation_children locks this in, asserting waiting_count == 0 for a blocked child.

Each decision is individually defensible. Together they leave the "awaiting permission" state of a delegated sub-agent with no surface at all except manually expanding the delegation card — which requires already suspecting something is wrong.

Nothing in the logs either

With logging at the default Info level, grep -i permission across the entire ~/.codeg/logs/ directory (three days of logs, ~2.5 MB) returns zero matches. Connection spawn, status_changed, fs policy and Initialize round-trips are all logged; permission requests are not logged at any point. So there is no post-hoc way to confirm a stall was a permission wait, and no way to script a watchdog around it.

For reference, a delegated spawn does log clearly:

[ACP] spawning connection id=… owner_window=main agent=Grok
  span: { agent_type: "Grok", parent_connection_id: "…", parent_tool_use_id: "", name: "delegation_task" }

Side observation, offered without a claim of causation: parent_tool_use_id is an empty string in that delegation_task span, while DelegationContext indexes bindings by parent_tool_use_id. That may be unrelated (this is the spawn span, not the delegation_started envelope), but it seemed worth mentioning to anyone tracing this code path.

Impact

• The orchestrating agent cannot distinguish work from a permission wait, so it cannot report the stall or route around it. This is the concrete, permission-specific case of 缺乏派发subagent状态的监视 #428.
• The human gets no signal, so recovery is guesswork plus manual inspection.
• Sound notifications ("Permission request" event) and the pet badge, the two things a user would reasonably expect to fire, both stay silent for delegated children.

Current workaround

Pre-authorize the sub-agent so it never asks: for Grok, set [ui] permission_mode in ~/.grok/config.toml (Settings → Agents → Grok → Permission mode); for Codex, set the approval policy to never. This works because those settings live in each agent's own global config, which is read whether the agent runs as a tab or as an ACP-hosted delegation child.

It trades the stall for the loss of the permission boundary entirely — and per #436, deny rules are not reliably enforced under Codeg's ACP hosting anyway, so there is currently no middle ground.

Suggested directions

Any one of these would remove the dead end:

1. Surface a pending child permission on the parent's delegation card — a badge or status change on the collapsed card would be enough; the full inline routing from delegation-context.tsx is not required to make it visible.
2. Let the pet badge/panel count delegation children that are awaiting permission specifically, even while continuing to exclude them from the session list (the count and the list already come from one payload, so this would mean splitting that).
3. Emit a log line (Info) on permission request/response, including the connection id and whether it is a delegation child. Cheap, and it makes external watchdogs possible.
4. Make the delegation-status MCP tool distinguish running from awaiting_permission, so the orchestrating agent can report the stall itself rather than waiting indefinitely.

Happy to test a patch or provide more log detail.

Related: #428 (no monitoring of dispatched sub-agent state — broader), #436 (Grok permission rules bypassed under ACP hosting), #440 (background task indicator stuck after cancelling a delegated task).