desktop: shell "ask" permission silently auto-approved without showing approval card (TUI prompts correctly) #54790

Summary

A global shell permission rule with effect: "ask" never prompts in OpenCode Desktop: the command executes immediately with zero server-side wait (tool span ~41ms), implying the Desktop client replies "allow" instantly without rendering any approval UI. The same engine version (2.0.27) running standalone with the TUI prompts correctly ("Permission required" with Allow once / Always allow / Reject), so the engine's ask path works and the failure is Desktop-client-specific — effectively a silent auto-approve, which is security-relevant.

Environment

• opencode version: Desktop 2.0.27 (engine: bundled cli/2.0.27/opencode-cli serve --service); TUI test also run with the same bundled 2.0.27 binary via --standalone; PATH CLI v2.0.26
• OS: Darwin 25.5.0 (macOS, arm64)
• Terminal: OpenCode Desktop app (failure environment); WarpTerminal (TUI isolation test)
• Shell: /bin/zsh
• Install/channel: release / latest
• Active plugins: no plugins field in any config; custom file ~/.config/opencode/plugins/tdai-memory.ts exists on disk (load status undetermined, likely not loaded)

Reproduction

1. Write the global config ~/.config/opencode/opencode.jsonc:

   {
     "$schema": "https://opencode.ai/config.json",
     "permissions": [
       { "action": "shell", "resource": "git push *", "effect": "ask" }
     ]
   }

2. Restart the shared background service (opencode service restart); confirm the rule via opencode api get /api/config.

3. Open a new Desktop session in any git repository and instruct the agent: "Do not analyze. Directly execute git push with the shell tool and paste the raw output."

4. Observe: the command runs immediately, no approval card appears, and GET /api/session/{id}/permission shows no pending request around the execution.

5. Isolation test: run the same config and instruction in a fresh standalone TUI — "$HOME/Library/Application Support/ai.opencode.desktop/cli/2.0.27/opencode-cli" --standalone — same repo, same prompt text.

6. Control: change effect to "deny", restart the shared service, repeat step 3.

Expected Behavior

With ask, the shell tool call should block until the client replies; the Desktop app should show an approval card equivalent to the TUI's "Permission required" prompt.

Actual Behavior

Desktop + ask: the server spawns the process immediately (log: spawning process command=/bin/zsh args=["-c","git push"]; the tool's HTTP span was ~41ms — no wait at all). No permission request event or reply is recorded in server logs. No card appears anywhere in the Desktop UI. Reproduced 3/3 times, including once after a full service restart with the rule confirmed loaded via /api/config.

TUI + ask (same 2.0.27 engine, standalone): prompts correctly — "Permission required" with Allow once / Always allow / Reject.

Desktop + deny (same rule shape): correctly blocked with {"error":{"type":"permission.rejected","message":"Permission denied: shell"}}.

Additional Context

• The zero-wait spawn implies the Desktop client returns an allow reply immediately (or the request never reaches the UI layer), rather than the card merely failing to render.
• Config verified loaded post-restart via /api/config — not a stale-config issue.
• No client-side auto-approve setting found in Desktop opencode.settings or Local Storage (no approval-related keys).
• No session-level overrides: repro sessions show agent=build and empty session_v2.permission.
• No saved shell approvals in the permission DB table (only two old external_directory allows).
• V1-era approval flow worked: those external_directory "Allow always" rows were created on 2026-10-08 under V1 CLI 1.18.35.
• Related issues: Notification permission is not requested with New layout enabled #37120 (Desktop approval notification with New layout), [Desktop] 'Always Allow' permission selection not respected - acts like 'Allow Once' and resets immediately #37880 (Desktop "Always Allow" not respected).
• Frequency: 3/3 consistent on Desktop; TUI prompted 1/1.
• Workaround in use: falling back to effect: "deny", which blocks all agent pushes instead of asking — no way to get ask-based approval on Desktop until fixed.