[Bug][Grok Build CLI] Non-always-approve permission modes fail all privileged tool calls with "unknown permission option" (approval popup has no effect)

[lidao2026-Coding]

Problem

Grok Build CLI (agent stdio / ACP mode, agent 1.0.0) fails every privileged tool call when the permission mode is not always-approve. With permission_mode set to default, auto, or ask, tools such as terminal commands, web_fetch, and MCP tools (use_tool) all fail immediately with:

Failed to request permission from user: unknown permission option for tool `run_terminal_command`

Key observations (reproduced over three rounds of testing, 2026-08-09):

• The client's permission confirmation popup does appear, but clicking "Allow" has no effect — the tool is still cancelled instantly.
• Read-only exempt tools (read_file / grep / list_dir / todo_write / search_tool) work fine in every mode (documented "never prompt" list).
• Only permission_mode = "always-approve" makes all privileged tools work.

Steps to reproduce

1. Set the permission mode to default or auto (e.g. [ui] permission_mode = "default" with yolo = false).
2. Ask the agent to call any privileged tool: run_terminal_command (e.g. gh repo view ...), web_fetch, or an MCP tool via use_tool.
3. Observed: the turn fails with Failed to request permission from user: unknown permission option for tool 'X' and stop_reason=cancelled. A permission popup may appear in the client, but approving it does not help.
4. Switch back to permission_mode = "always-approve" (yolo = true): the same tool call executes immediately.

Root cause analysis

• Not a yolo / permission_mode pairing issue: yolo = false + permission_mode = "default" (the exact factory-default pair) still fails.
• Not a "request never reached the client" issue: the permission popup demonstrably appears.
• The failure happens inside the engine's permission pipeline: the error text is generated by the agent itself (tool_call_update status=failed in the ACP event stream). The engine fails to build a permission option for tools like run_terminal_command / web_fetch / use_tool, reports it as user rejected permission, and cancels the call — regardless of whether the user approved.
• Why always-approve works: per the official permissions doc (22-permissions-and-safety.md), always-approve short-circuits the pipeline after step 2 and never constructs a permission request, so the defect is bypassed.

Expected behavior

• In default / auto / ask modes, the permission prompt approval should let the tool execute normally.
• At minimum, a non-always-approve mode should surface a clear degradation notice instead of silently failing every privileged call.

Additional context

• Platform: Windows 11 x86_64, Grok Build 0.2.118 / agent 1.0.0, reproduced through the grok-app desktop ACP client (Tauri 2).
• Suspected engine defect: the non-always-approve permission pipeline fails to resolve permission options for run_terminal_command / web_fetch / use_tool under ACP.
• Related evidence: client-injected hooks all fail on Windows (pre_tool_use → os error 193; user_prompt_submit / stop / post_tool_use → exit code 1), suggesting broader ACP integration friction, though hooks are fail-open and do not block tools.
• Filed here (same channel as [Bug][Grok Build CLI]: Responses API SSE decoding crashes on web_search_call items missing 'action' field (server-side search broken for BYOK providers like DeepSeek) #193) because xai-org/grok-build has GitHub issues disabled.