codex - 💡(How to fix) Fix Codex app permission mode changes apply across chats instead of the active chat

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

26.513.20950 (2816)

What subscription do you have?

Not included here; this appears to be local app/runtime behavior rather than plan-specific behavior. I can provide it if needed.

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

In the macOS Codex desktop app, changing the permission mode in one chat appears to apply that permission mode globally across other chats, instead of being scoped to the active chat/thread.

This is surprising and potentially unsafe for multi-chat workflows. If I raise permissions for one high-trust task, unrelated existing or new chats appear to inherit that raised mode. Conversely, lowering permissions for one chat affects other active work.

The app UI makes this feel like a chat/session control, but the observed effect is app-wide. If the intended behavior is app-wide defaults, the UI should make that explicit. If the intended behavior is chat-local permissions, the app should persist/apply the mode per thread.

What steps can reproduce the bug?

1. Open Codex.app on macOS.
2. Start or open Chat A.
3. Use the permission mode control in Chat A and switch to a different mode, for example Full Access or Auto-review.
4. Open or start Chat B in the same Codex.app instance.
5. Observe that Chat B now shows/uses the same permission mode change from Chat A.
6. Switch the mode in Chat B.
7. Return to Chat A and observe that the permission mode has changed there as well.

What is the expected behavior?

Either:

1. Permission mode changes made from a chat are scoped to that chat/thread and do not alter other chats, or
2. The control is clearly labeled as an app-wide/default permission setting so users understand that changing it affects all chats.

For safety, I think chat/thread-local behavior is the better default. A broad permission grant for one task should not silently change the safety envelope for unrelated chats.

Additional information

I checked the public repo before filing this. The public contribution policy says unsolicited PRs are not accepted, so I am filing this as an issue with analysis rather than opening a PR.

Relevant public app-server/protocol evidence from openai/codex at e6a73688105735c73cfc21b16c9701e2c05b7849:

• codex-rs/app-server/README.md documents that thread/start, thread/resume, and thread/fork accept permission override rules. This suggests thread-level permission selection is already supported at the app-server boundary.
• codex-rs/app-server/README.md also says approval requests include threadId and turnId, and clients should scope UI state to the active conversation.
• codex-rs/app-server-protocol/schema/typescript/v2/TurnStartParams.ts describes approvalPolicy and sandboxPolicy as overrides for the current turn and subsequent turns, not global app settings.
• The same README exposes config/value/write and config/batchWrite for writing user config.toml, including desktop.* keys. My root-cause hypothesis is that the desktop app permission mode control may be persisting a global/user config value rather than applying a thread/turn-scoped override.

Potential fix direction:

• Treat the permission mode selector in a thread as thread-local state.
• On thread creation/resume/turn start, pass the selected permission profile / approval policy / sandbox policy through the existing thread/start, thread/resume, thread/fork, or turn/start override fields.
• Avoid writing the active thread's permission selection into global user config unless the user explicitly chooses a global default setting.
• If global behavior is intentional, rename/relabel the control to make that scope explicit, for example “Default permissions for all chats”.

I am happy to help with a targeted PR if a maintainer confirms this is the desired behavior and invites an external contribution.