[Windows app] Realtime Voice rewrites Full access to Custom and mutates config.toml

What version of the Codex App are you using (From “About Codex” dialog)?

Codex desktop app 26.810.7004.0 with bundled Codex CLI 0.148.0-alpha.9.

What subscription do you have?

Not relevant to this local permission-state regression.

What platform is your computer?

Windows x64 desktop app.

What issue are you seeing?

Creating a brand-new Realtime Voice task silently changes an explicit Full access configuration into Custom by rewriting the persistent approval policy.

Before Voice starts, the desktop UI and persisted host state both report full-access, and the user config contains:

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

There is no explicit sandbox_mode entry.

At the moment a new Voice task is launched, config.toml is rewritten to:

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

The resulting Voice task records:

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 permissions control consequently displays Custom. The filesystem sandbox is still disabled, but the newly introduced on-request approval policy can block tool calls. This is particularly disruptive in Voice and remote workflows because the approval prompt may not be actionable while Voice is active.

A normal task created earlier under the same running app process correctly recorded:

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

The global and local persisted agent modes remain full-access, and no remote host is selected. This reproduces without SSH, MCP, a project-level config, an alternate config directory, or dotfile/symlink indirection.

What steps can reproduce the bug?

1. In the Windows desktop app, select Full access.
2. Configure:

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

1. Fully quit and reopen the app.
2. Confirm a normal new task starts with Full access and approval_policy = "never".
3. From the home composer, start a brand-new Voice chat.
4. Observe that its permissions indicator shows Custom.
5. Inspect the effective Voice turn context and user config.
6. Observe that Voice uses approval_policy = "on-request" and that the persistent config has been rewritten accordingly.

The config modification timestamp occurs immediately before the Realtime Voice session is created.

What is the expected behavior?

A new Voice task should inherit the explicitly selected Full-access mode and approval_policy = "never".

Starting Voice should not mutate persistent permission settings. If Voice intentionally requires a different approval policy, the app should disclose that before launch and provide a usable approval flow instead of silently switching to Custom.

Additional information

This appears broader than #38469:

• #38469 reports an unclickable approval modal in a Voice-created task over SSH on macOS.
• This report captures the preceding permission-state/config mutation on Windows and reproduces without SSH or MCP.
• The silent switch to on-request may explain why Voice-created tasks unexpectedly reach the blocked approval state described there.

The desktop implementation appears to have a Voice creation path that may use the app-server permission default instead of sending the currently selected permission override. Regardless of the internal path, the observed behavior is that an explicit user choice is not preserved and persistent config is changed at Voice launch.

No local paths, usernames, hostnames, task contents, task IDs, or raw logs are included in this report.