Voice assistant bug

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

• #37778

Powered by Codex Action

note am using ssh connection
this is no mcp approval no duplication found

I can reproduce a closely related failure on Windows, and the local session/config evidence shows that starting Realtime Voice itself changes the approval policy.

Environment

• Codex desktop app: 26.810.7004.0
• Bundled Codex CLI: 0.148.0-alpha.9
• Windows desktop app

Starting state

• Permissions UI: Full access
• Global and local persisted agent mode: full-access
• No remote host selected
• User config:

``toml
default_permissions = ":danger-full-access"
approval_policy = "never"
``

• No explicit sandbox_mode entry

A normal new task created under the same app process had:

• thread_source = "user"
• approval_policy = "never"
• sandbox_policy.type = "danger-full-access"
• permission_profile.type = "disabled"

Reproduction

1. Clear the prior Voice-task pointer and restart the desktop app.
2. Confirm the global and local permission selections are Full access.
3. Start a brand-new Voice chat.
4. The permissions indicator changes to Custom.

Observed evidence
At the moment Voice launched, the user config was rewritten to:

approval_policy = "on-request"
default_permissions = ":danger-full-access"
sandbox_mode = "danger-full-access"

The new Voice task then recorded:

• thread_source = "realtime_voice"
• realtime_active = true
• approval_policy = "on-request"
• approvals_reviewer = "user"
• sandbox_policy.type = "danger-full-access"
• permission_profile.type = "disabled"

The config write occurred immediately before the Voice session was created. The global/local persisted agent modes remained full-access, so the UI cache and explicit Full-access selection were not what changed. Voice changed the effective approval policy to on-request, producing the Custom label and creating approval requests that can block a Voice workflow.

This also reproduces without an SSH host, so the underlying permission override does not appear to be SSH-specific, although remote Voice makes the impact worse.

Expected behavior
A new Voice task should inherit the explicitly selected Full-access mode and configured approval_policy = "never". Starting Voice should not mutate persistent permission settings. If Voice intentionally requires a safer approval policy, it should disclose that before launch and provide a usable approval flow rather than silently changing the mode.

I filed #38790 for the broader Windows/local reproduction where starting a brand-new Realtime Voice task rewrites an explicit Full-access configuration from approval_policy = "never" to on-request, causing the task to display Custom. This is related to the blocked approval symptom here, but it reproduces without SSH or MCP and captures the persistent config mutation that precedes it.