[Windows Desktop 26.818] Full Access applies for one turn, but composer silently reverts with no turn-level indicator

What version of the Codex App are you using?

ChatGPT/Codex desktop app 26.818.21641 with bundled codex-cli 0.148.0-alpha.21.

What platform is your computer?

Windows x64 desktop app.

What issue are you seeing?

A manually selected Full Access permission override is applied to the submitted turn, but immediately after the turn the composer shows the configured default permission profile again. The conversation history does not show which permission mode was used for the previous turn.

This makes it look as if Full Access was never enabled, even though the effective turn context confirms that it was.

The user-level configuration is:

default_permissions = "workspace-network"

[permissions.workspace-network]
description = "Workspace sandbox with unrestricted outbound network access."
extends = ":workspace"

[permissions.workspace-network.network]
enabled = true

[permissions.workspace-network.network.domains]
"*" = "allow"

Observed effective context for the submitted Full Access turn:

sandbox_mode = danger-full-access
permission_profile.type = disabled
filesystem = unrestricted
network = enabled

Immediately afterward, the permission pill under the composer displays:

workspace-network

The default profile itself is working correctly on the next turn. The problem is that the UI provides no durable indication that the previous turn ran with Full Access, and the silent reset is easily interpreted as a failed selection.

What steps can reproduce the bug?

1. Configure a named custom permission profile as default_permissions, such as workspace-network above.
2. Fully restart the Windows desktop app.
3. Open a local task and confirm that the composer shows workspace-network.
4. Select Full Access from the permission control.
5. Submit a message.
6. Inspect the effective turn context and confirm that it uses danger-full-access with an unrestricted filesystem.
7. After the turn completes, inspect the composer.
8. Observe that the composer immediately shows workspace-network again.
9. Inspect the conversation history and observe that there is no visible turn-level badge or other indication that the previous message ran under Full Access.

What is the expected behavior?

The app should make the state transition unambiguous. Any of the following would resolve the confusion:

• keep Full Access selected until the user changes it;
• explicitly state that the selection applies to one turn and will reset to the default profile;
• show the effective permission mode on the submitted user message or completed turn;
• briefly show a confirmation such as “Sent with Full Access; next turn uses workspace-network.”

At minimum, the user should be able to tell from the conversation which permission mode was actually used for a completed turn.

Additional information

The underlying permission enforcement appears correct: Full Access was observed for the submitted turn, and the custom default profile was observed again on the following turn. This report is specifically about permission-state visibility and the silent reset behavior in the desktop composer.

Related but not identical reports:

• #25810 — new threads/handoffs do not consistently inherit visible Full Access state
• #38535 — the permission selector can stop indicating that an effective full-access configuration came from config.toml
• #32862 — existing tasks can rehydrate with older approval/sandbox state

No credentials, account identifiers, task identifiers, or private repository contents are included.

Start at the Windows desktop composer’s permission control and trace what happens after a turn submitted with Full Access. Verify how the completed turn records or displays its effective permission mode, then make the reset to workspace-network unambiguous in the composer or conversation history and reproduce the listed steps.