Skip to content

VS Code custom permission profile overrides on-request/auto_review with never/user #33084

Closed

Description

@WilliamK7

What version of the IDE extension are you using?

26.707.71524

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Linux 6.18.33.2-microsoft-standard-WSL2 x86_64 x86_64

What issue are you seeing?

Selecting a named custom permission profile in the VS Code extension overrides the configured approval policy and approval reviewer.

My ~/.codex/config.toml contains:

approval_policy = "on-request"
approvals_reviewer = "auto_review"

default_permissions = workspace-network

[permissions.workspace-network]
extends = ":workspace"

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

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

When I create a new chat and select the built-in “Approve for me” mode, the extension correctly starts the turn with:

requestApprovalPolicy=on-request
requestApprovalsReviewer=auto_review
requestPermissionProfile=null
resolvedApprovalPolicy=on-request
resolvedApprovalsReviewer=auto_review

However, when I create another new chat and select the custom workspace-network profile, the extension sends:

requestApprovalPolicy=never
requestApprovalsReviewer=user
requestPermissionProfile=workspace-network
resolvedApprovalPolicy=never
resolvedApprovalsReviewer=user

Therefore, selecting the custom permission profile changes two independent settings:

  • approval_policy: on-request → never
  • approvals_reviewer: auto_review → user

This disables auto-review and prevents actions that require escalation from being reviewed.

This is a regression. With extension version 26.707.41301 (bundled codex-cli 0.144.0-alpha.4) on 2026-07-13, the same custom profile correctly produced:

requestApprovalPolicy=on-request
requestApprovalsReviewer=auto_review
requestPermissionProfile=workspace-network
resolvedApprovalPolicy=on-request
resolvedApprovalsReviewer=auto_review

What steps can reproduce the bug?

  1. Add the following configuration to ~/.codex/config.toml:

    approval_policy = "on-request"
    approvals_reviewer = "auto_review"
    
    default_permissions = workspace-network
    
    [permissions.workspace-network]
    extends = ":workspace"
    
    [permissions.workspace-network.network]
    enabled = true
    allow_upstream_proxy = true
    
    [permissions.workspace-network.network.domains]
    "*" = "allow"
  2. Reload VS Code.

  3. Open the Codex extension.

  4. Start a new chat.

  5. Select the custom permission profile workspace-network.

  6. Send any prompt.

  7. Inspect the Codex extension log.

The turn-start log reports:

requestApprovalPolicy=never
requestApprovalsReviewer=user
requestPermissionProfile=workspace-network

For comparison:

  1. Start another new chat.
  2. Select “Approve for me”.
  3. Send the same prompt.

The log then correctly reports:

requestApprovalPolicy=on-request
requestApprovalsReviewer=auto_review
requestPermissionProfile=null

What is the expected behavior?

Selecting a named permission profile should apply that profile’s filesystem and network permissions without silently
overriding the separately configured approval settings.

With the configuration above, the custom profile should start the turn with:

requestApprovalPolicy=on-request
requestApprovalsReviewer=auto_review
requestPermissionProfile=工作区联网

This was the behavior of extension version 26.707.41301.

### Additional information

- The problem reproduces in completely new chats; no context compaction, resume, or restart of an existing thread is involved.
- Standalone `codex-cli 0.144.4` uses the same `config.toml` correctly. The issue appears specific to the VS Code extension’s turn-start request construction.
- The regression appeared after updating from extension `26.707.41301` / bundled CLI `0.144.0-alpha.4` to extension `26.707.71524` / bundled CLI `0.144.2`.

Activity

  1. added
    bugSomething isn't working
    configIssues involving config.toml, config keys, config merging, or config updates
    on Jul 14, 2026
  2. github-actions commented on Jul 14, 2026

    @github-actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. liby commented on Jul 15, 2026

    @liby

    Additional confirmed reproduction from macOS Codex Desktop.

    Session metadata:

    • Originator: Codex Desktop
    • Session source: vscode
    • Bundled Codex CLI: 0.144.2
    • Standalone Codex CLI: 0.144.4

    Configuration:

    approval_policy = "on-request"
    approvals_reviewer = "auto_review"
    default_permissions = "<named custom profile>"

    After fully restarting the app and creating a fresh thread, the first turn context recorded:

    approval_policy = never
    approvals_reviewer = user
    permission_profile.type = managed
    sandbox_policy.type = workspace-write
    

    The resulting permission profile included the configured additional writable roots, so the named profile was being applied. The two independent approval settings were nevertheless replaced with never and user.

    No context compaction or thread resume was involved. With the same configuration, standalone codex doctor --json reported config.load as ok and sandbox.helpers reported approval policy OnRequest.

  4. WilliamK7 commented on Jul 16, 2026

    @WilliamK7
    Author

    Seems to be fixed in 26.707.91948, I'll close this issue now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingconfigIssues involving config.toml, config keys, config merging, or config updatesextensionIssues related to the VS Code extension

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions