[Windows app] Permission dropdown desyncs while runtime profiles change or merge between prompts

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

26.707.3748.0

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The permission profile displayed in the Codex App composer frequently does not match the permission policy delivered to the agent. The effective profile can also change between prompts without any interaction with the permission picker.

This began after the update that merged the Chat and Codex app experiences.

Examples observed in one task:

• The composer displayed a custom repo-contained profile, but the agent received unrestricted Full Access (danger-full-access).
• The composer displayed the custom profile while the agent continued receiving Ask for Approval or Approve for Me.
• After manually selecting the custom profile, the agent sometimes received a hybrid policy: the filesystem and network rules came from the custom profile, but approvals_reviewer = "auto_review" remained from the previously selected Approve for Me profile.
• Manually reselecting a profile that was already shown as selected sometimes changed the effective permissions.
• Sending another prompt without touching the picker sometimes changed the effective policy from the repo-contained profile to Full Access.
• The composer itself sometimes changed its displayed profile immediately after submitting a prompt.
• The behavior occurred both when submitting with Enter and when clicking the Send button.
• Selecting Custom (config.toml) unexpectedly produced a strict read-only policy.
• A configured approval_policy = "on-request" was still delivered to the agent as never on the following prompt.
• The custom profile configured only minimal reads outside the repository, but some received policies contained filesystem-root read access instead.

This is a security concern because the UI can indicate that the agent is restricted to the repository while the effective policy grants unrestricted filesystem and network access.

The following effective permission states were observed:

Custom repo-contained profile:
permission_profile.type = managed
sandbox_mode = workspace-write
network = enabled
repository and .git = writable

Full Access:
permission_profile.type = disabled
sandbox_mode = danger-full-access
approval_policy = never
filesystem = unrestricted
network = enabled

Approve for me:
permission_profile.type = managed
sandbox_mode = workspace-write
approvals_reviewer = auto_review
network = restricted
.git = read-only

Unexpected hybrid after switching from Approve for Me to the custom profile:
permission_profile.type = managed
sandbox_mode = workspace-write
approvals_reviewer = auto_review
network = enabled
repository and .git = writable

What steps can reproduce the bug?

1. Open the Codex desktop app on Windows and open a local Git repository.

1. Configure a named permission profile in the user-level config.toml:

```toml
approval_policy = "on-request"
default_permissions = "repo-autonomous"

[permissions.repo-autonomous.workspace_roots]
'X:\path\to\repository' = true

[permissions.repo-autonomous.filesystem]
":minimal" = "read"

[permissions.repo-autonomous.filesystem.":workspace_roots"]
"." = "write"
".git" = "write"

[permissions.repo-autonomous.network]
enabled = true

[permissions.repo-autonomous.network.domains]
"*" = "allow"

1. Select repo-autonomous from the permission dropdown.

1. Confirm that the dropdown displays repo-autonomous.

1. Send a prompt asking the agent to report the effective permission metadata it received, including:

permission_profile.type
sandbox mode
approval policy or approval reviewer
network access
filesystem read rules
writable roots

1. Compare the reported runtime policy with the profile shown in the dropdown.

1. Send several more prompts without touching the permission picker.

1. Observe one or more of the following:

The dropdown changes to another profile immediately after sending.
The dropdown continues to display repo-autonomous, but the runtime receives Full Access:
permission_profile.type = disabled and sandbox_mode = danger-full-access.
The runtime changes between prompts without the permission picker being touched.
Reselecting the already-displayed custom profile changes the runtime policy.
The custom profile receives approval_policy = never even though on-request is configured.
The custom profile receives filesystem-root read access even though only :minimal read access is configured.

1. Select Approve for Me, send a prompt, and verify that the runtime receives:

approvals_reviewer = auto_review
network = restricted
.git = read-only

1. Switch back to repo-autonomous and send another prompt.

1. In some attempts, observe a hybrid runtime policy:

approvals_reviewer = auto_review
network = enabled
repository and .git = writable
The filesystem and network fields come from repo-autonomous, while auto_review remains from Approve for Me.

1. Select Full Access, send a prompt, then switch back to the custom profile and continue sending prompts without touching the picker.

1. Observe that the effective runtime can alternate between the repo-contained profile and Full Access.

The display mismatch occurred when submitting with Enter and when clicking the Send button.
The behavior is intermittent, but repeated profile changes and several consecutive prompts usually reproduce at least the display/runtime mismatch. In my testing, the effective runtime also changed without user interaction.

What is the expected behavior?

What is the expected behavior?

The selected permission profile should be applied atomically and remain stable until the user explicitly changes it.

Specifically:

• The profile displayed in the composer should match the effective runtime policy sent with the next prompt.
• Sending a prompt should not change either the displayed profile or the effective runtime profile.
• The runtime should never receive Full Access while the composer displays a repo-contained profile.
• Switching profiles should replace the complete policy rather than retain fields such as approvals_reviewer from the previously selected profile.
• Reselecting a profile that is already displayed as selected should be a no-op.
• The configured approval_policy = "on-request" should allow escalation requests outside the permitted repository boundaries.
• Actions inside the configured repository, including writes to .git, should run without repeated approval prompts.
• Filesystem access outside the repository should remain at the configured :minimal level and should not become filesystem-root read access.
• Keyboard submission and clicking the Send button should produce identical behavior.

If the application cannot apply a selected profile, it should fail closed and visibly report the error. It should not silently apply or retain a more permissive profile.

Additional information

Related issue

This is related to #29586, where the permission dropdown changes after sending while the runtime remains Full Access.

This report differs because the effective runtime policy also changed between prompts without user interaction. In addition, switching profiles sometimes produced a hybrid policy containing filesystem/network permissions from one profile and the approval reviewer from another.

Installed application packages

Windows package inspection shows that both of the following packages remain installed:

• OpenAI.Codex 26.707.3748.0
• OpenAI.ChatGPT-Desktop 1.2026.190.0

Only processes belonging to the OpenAI.Codex package were running during testing. Its UI executable is named ChatGPT.exe. No process from the separately installed OpenAI.ChatGPT-Desktop package was active, and I could not confirm that it remains independently launchable.

This may be unrelated, but I am including it because the problem began after the merged Chat/Codex app update and could potentially involve persisted or migrated application state.