`--allow-all` read permissions leak to the UI dispatcher and wedge the TUI (no input box) on `-i`/`--resume` startup

[dfederm]

Bug: --allow-all read permissions leak to the UI dispatcher and wedge the TUI (no input box)

Summary

When launching a session non-interactively (copilot --allow-all … -i "@<file>") or resuming one (copilot --allow-all --resume=<id> …), read-kind permission requests that should be auto-approved at the session/wire layer are instead surfaced to the UI dispatcher. The TUI comes up and renders/scrolls, but there is no input box and the session is completely unresponsive to keyboard input. No work is performed. Starting a session plain-interactively (copilot, then typing/pasting the prompt) does not reproduce it.

Environment

• GitHub Copilot CLI 1.0.63 (copilot/1.0.63 (win32 v24.16.0))
• OS: Windows (Windows Terminal; tabs spawned via wt -w 0 new-tab … pwsh -NoLogo -EncodedCommand …)
• Folder already trusted: ~/.copilot/config.json → "trustedFolders": ["D:\\Code"] (both working dirs are under D:\Code, so this is not a first-time folder-trust prompt)
• Possibly-relevant experiment flights in config.json (NOT confirmed as the cause — listed only as leads): cfdic-spawn, cli_aa_c, cli_aa_monitor_t, and params copilot_cli_shell_spawn_backend: true, copilot_cli_remove_parallel_tool_prompt: true.

Impact

• Any automation that launches/resumes Copilot non-interactively with --allow-all -i "@file" / --resume produces a dead, input-less TUI.
• Hit both a freshly-launched tab and a --resume tab in the same session. Repeating via the /resume command reproduced it as well.
• Only workaround found: start copilot interactively (no -i, no --resume) and paste the prompt by hand.

Steps to reproduce

1. In a trusted folder (folder already in trustedFolders), run either:
   • Launch: copilot --allow-all --name <key> --reasoning-effort max -i "@<path-to-prompt>.md"
   • Resume: copilot --allow-all --resume=<session-id> --reasoning-effort high -i "@<path-to-prompt>.md"
2. On startup the CLI prompts to add the directory to the allow list (unexpected — --allow-all is set and the folder is already trusted). Approve it.
3. The session UI appears and scrolls, but there is no input box and it accepts no keyboard input. No agent work happens.

Expected: with --allow-all, permission requests are auto-approved at the session/wire layer and the session is interactive (or, for -i, immediately starts working on the seeded prompt).

Actual: read permission requests are dispatched to the UI layer, which never yields an interactive input box; the session is wedged.

Evidence (from a --resume tab's process log)

The error fires repeatedly through startup — at foreground-session registration, extension/tool registration, and every MCP client connect:

15:27:35.428 [INFO]  Welcome <user>!
15:27:35.434 [ERROR] PermissionRequestPrompt: kind='read' surfaced to UI dispatcher. Expected to be auto-approved at the session or wire layer.
15:27:35.435 [INFO]  Unregistering foreground session: <session-id>
15:27:35.436 [INFO]  Registering foreground session: <session-id>
15:27:35.441 [ERROR] PermissionRequestPrompt: kind='read' surfaced to UI dispatcher. …
15:27:35.821 [ERROR] PermissionRequestPrompt: kind='read' surfaced to UI dispatcher. …
15:27:35.912 [ERROR] PermissionRequestPrompt: kind='read' surfaced to UI dispatcher. …
15:27:36.263 [ERROR] PermissionRequestPrompt: kind='read' surfaced to UI dispatcher. …   (during MCP client startup)
15:27:38.117 [ERROR] PermissionRequestPrompt: kind='read' surfaced to UI dispatcher. …
15:27:38.214 [ERROR] PermissionRequestPrompt: kind='read' surfaced to UI dispatcher. …
15:27:38.714 [ERROR] PermissionRequestPrompt: kind='read' surfaced to UI dispatcher. …
15:27:39.091 [ERROR] PermissionRequestPrompt: kind='read' surfaced to UI dispatcher. …
15:27:39.276 [ERROR] PermissionRequestPrompt: kind='read' surfaced to UI dispatcher. …

The log message itself states the invariant that's being violated: these reads were "Expected to be auto-approved at the session or wire layer." With --allow-all set, none of these should reach the UI dispatcher.

(Same symptom independently observed on the freshly-launched tab for a different worktree under D:\Code.)

Cross-session falsification check

Counting genuine runtime occurrences (anchored on the ISO-timestamped [ERROR] line) across all sessions on this machine this morning gives a clean split — the error is present in every wedged tab and absent from every working session:

Session	startup	true error count	outcome
A (long-running)	interactive	0	working
B — 3 auto-launch attempts	--allow-all -i "@file"	17 / 36 / 45	wedged
C — 3 auto-launch/resume attempts	--allow-all --resume -i "@file"	15 / 36 / 33	wedged
B — manual recovery	interactive (paste prompt)	0	working
C — manual recovery	interactive (paste prompt)	0	working
A — later, same session	interactive	0	working

100% of wedged tabs emit the error; 0% of working sessions do. The discriminating factor is non-interactive startup (-i "@file" / --resume) vs plain interactive. (Caveat: this is tight correlation across one machine / one morning, not a traced causal mechanism — no stack trace was captured showing the input box being suppressed.)

Likely cause / hypothesis

A regression in the permission auto-approval path: under --allow-all (and/or the cfdic-spawn / copilot_cli_shell_spawn_backend experiment), read-kind PermissionRequestPrompts are not being satisfied at the session/wire layer and fall through to the interactive UI dispatcher. Because these fire during non-interactive startup (-i/--resume), the dispatcher ends up in a state with no usable input affordance, leaving the TUI rendered but dead.

Workaround

Start copilot interactively (no -i, no --resume) and paste the prompt manually; rename the session afterward if needed. This avoids the wedged dispatcher.

Asks

• Ensure read permissions are auto-approved at the session/wire layer (especially under --allow-all) and never surface to the UI dispatcher during non-interactive (-i / --resume) startup.
• If the cfdic-spawn / copilot_cli_shell_spawn_backend flight is implicated, consider gating/rolling it back while the auto-approve path is fixed.