[Windows Desktop 26.901] Custom read-only profile silently switches to Full Access

What version of the Codex App are you using?

ChatGPT/Codex desktop app 26.901.20858 with bundled Codex CLI 0.153.0-alpha.5.

What platform is your computer?

Windows x64, OS build 26200.

What issue are you seeing?

A local desktop task configured to use a custom read-only permission profile silently switches to Full Access between turns.

The custom profile is the configured default:

approval_policy = "on-request"
default_permissions = "colleague"

[permissions.colleague]
extends = ":read-only"

[permissions.colleague.network]
enabled = false

The user did not select Full Access, and the assistant did not request elevation. After an ordinary assistant response with no intervening tool call, the composer displayed “Full access is on.” The next submitted turn arrived with :danger-full-access.

Manually selecting the custom colleague profile restores read-only behavior for a turn, but the task can revert to Full Access again afterward.

What steps can reproduce the bug?

1. On Windows Desktop, configure a named profile that extends :read-only and make it default_permissions.
2. Open a local task and confirm the custom profile is active.
3. Exchange ordinary text/image messages without selecting Full Access or requesting elevation.
4. Complete an assistant turn.
5. Observe that the composer can switch to Full access and show the warning banner.
6. Submit the next message and inspect the effective permission context.

Expected behavior

The task should remain on the configured custom read-only profile until the user explicitly selects Full Access. Full Access should never become active merely because a turn completed or the task UI rehydrated.

The assistant may ask the user to grant broader access, but the permission transition must remain an explicit user action.

Actual behavior

Sanitized local diagnostics show this transition:

Earlier turn:
permission_profile = Managed
active_permission_profile.id = "colleague"
sandbox_policy = ReadOnly { network_access: false }

Later turn:
permission_profile = Disabled
active_permission_profile.id = ":danger-full-access"
sandbox_policy = DangerFullAccess
approval_policy = Never

The current task record then persisted:

sandbox_policy = {"type":"disabled"}
approval_mode = never

No configuration file change occurred during the transition.

Impact

This is a security-sensitive permission escalation. The UI and effective task state can grant unrestricted filesystem and network access without the user intentionally selecting it.

The behavior appears related to task/composer permission-state persistence or rehydration. That is an inference, not a confirmed root cause.

Related issues

• #39729 reports a custom profile silently replacing a one-turn Full Access selection. This report is the inverse and security-sensitive direction: a custom read-only profile silently becomes Full Access.
• #32862 reports existing-task permission rehydration drift in the opposite direction.

No credentials, private file contents, local paths, screenshots, account identifiers, or conversation text are included.

Start by reproducing the Windows desktop task flow with a custom profile extending :read-only, then inspect the task/composer permission-state persistence and rehydration paths using the transition diagnostics in the report. Done means the configured profile remains active across ordinary turns and task rehydration, with Full Access requiring an explicit user selection; add or run coverage for that transition if the relevant tests are located.