Skip to content

Codex Desktop cannot start thread: permissionProfile/list unknown variant and PermissionProfileSelectionParams type mismatch #29159

Closed

Description

@VectorPeak

Summary

Codex Desktop cannot create a new task or send a message on Windows. The UI shows an error dialog or stays stuck on "Unable to send message / Loading...".

Local logs show two related failures:

  1. The Desktop frontend calls permissionProfile/list, but the local backend/app-server rejects it as an unknown request variant.
  2. thread/start fails because the permission profile selection is sent as a string such as ":danger-full-access", while the backend expects an internally tagged enum named PermissionProfileSelectionParams.

This appears to be a Codex Desktop frontend/backend protocol mismatch around permission profile APIs. It prevents conversations from starting at all.

Environment

  • App: Codex Desktop
  • OS: Windows
  • Codex package version: 26.616.4196.0
  • Package full name: OpenAI.Codex_26.616.4196.0_x64__2p2nqsd0c76g0
  • Model: gpt-5.5
  • Custom model provider: yes
  • Install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.616.4196.0_x64__2p2nqsd0c76g0
  • User data path shape: %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex
  • Config file path shape: %USERPROFILE%\.codex\config.toml

Reproduction Steps

  1. Open Codex Desktop on Windows.
  2. Start a new task or conversation.
  3. Type any message and click Send.
  4. Observe that the message cannot be sent, or the dialog remains stuck on "Loading...".

Expected Behavior

Codex Desktop should create the thread successfully and send the message.

Actual Behavior

The UI cannot send the message and may show:

Unable to send message
Loading...

Sometimes the toast/dialog also shows:

Invalid request: invalid type: string ":workspace", expected internally tagged enum PermissionProfileSelectionParams

or:

Invalid request: invalid type: string ":danger-full-access", expected internally tagged enum PermissionProfileSelectionParams

Relevant Logs

From local Codex Desktop logs:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\06\20\codex-desktop-89fd759a-fe97-44cc-aac2-becaa1acad3e-18808-t0-i1-014209-0.log

The local backend rejects permissionProfile/list:

2026-06-20T01:44:42.048Z error [electron-message-handler] Request failed conversationId=none durationMs=7 error={"code":-32600,"message":"Invalid request: unknown variant `permissionProfile/list`, expected one of `initialize`, `thread/start`, `thread/resume`, ..."} method=permissionProfile/list

Later, thread/start fails with a permission profile parameter type mismatch:

2026-06-20T01:45:36.305Z error [electron-message-handler] Request failed conversationId=none durationMs=7 error={"code":-32600,"message":"Invalid request: invalid type: string \":danger-full-access\", expected internally tagged enum PermissionProfileSelectionParams"} method=thread/start

Prewarming also fails:

2026-06-20T01:45:36.305Z warning [electron-message-handler] Failed to prewarm conversation cwd=%USERPROFILE%\Documents\Codex\2026-06-20\hi-o errorMessage="Invalid request: invalid type: string \":danger-full-access\", expected internally tagged enum PermissionProfileSelectionParams"

Config Notes

My %USERPROFILE%\.codex\config.toml does not explicitly set default_permissions or sandbox_mode.

Relevant non-sensitive config shape:

model_provider = "custom"
model = "gpt-5.5"
model_reasoning_effort = "high"
disable_response_storage = true

[model_providers]
[model_providers.custom]
name = "custom"
wire_api = "responses"
requires_openai_auth = true
base_url = "<custom responses-compatible endpoint>"

[desktop]
appearanceTheme = "system"
localeOverride = "en-US"

No explicit permission profile configuration is present.

Things Tried

  • Restarted Codex Desktop.
  • Checked %USERPROFILE%\.codex\config.toml; no explicit default_permissions or sandbox_mode is configured.
  • The issue still appears when creating or prewarming a conversation.
  • Searched existing issues for PermissionProfileSelectionParams and permissionProfile/list. I found related Desktop permission/sandbox issues, but not this exact startup failure or schema mismatch.

Related Issues Checked

Suspected Cause

The Desktop web frontend appears to be newer than the local app-server/backend, or the app-server is using an older protocol schema.

Evidence:

  • The frontend calls permissionProfile/list.
  • The backend responds with unknown variant permissionProfile/list.
  • thread/start receives a string such as ":danger-full-access" or ":workspace", but the backend expects PermissionProfileSelectionParams as an internally tagged enum.

This suggests a protocol/schema mismatch around permission profile selection.

Impact

This blocks normal use of Codex Desktop because a conversation cannot be created and messages cannot be sent.

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    app-serverIssues involving app server protocol or interfaces
    on Jun 20, 2026
  2. VectorPeak commented on Jun 20, 2026

    @VectorPeak
    Author

    Closing this issue as resolved.

    The root cause was a stale CODEX_CLI_PATH override on my local machine, which forced Codex Desktop to launch an older CLI/app-server:

    C:\Users\ZXY\AppData\Local\OpenAI\Codex�in�dex.exe

    That backend reported:

    0.130.0-alpha.5

    while the current Codex Desktop app expected to use its bundled backend:

    C:\Program Files\WindowsApps\OpenAI.Codex_26.616.4196.0_x64__2p2nqsd0c76g0�pp esources�dex.exe

    which reports:

    0.142.0-alpha.1

    Because of this frontend/backend version mismatch, the newer Desktop frontend sent newer protocol requests that the older backend could not understand, leading to errors such as:

    • unknown variant permissionProfile/list
    • unknown variant remoteControl/enable
    • unsupported feature enablement apps_mcp_path_override
    • Invalid request: invalid type: string ":workspace", expected internally tagged enum PermissionProfileSelectionParams

    I found two stale override sources:

    1. A user-level Windows environment variable:
      CODEX_CLI_PATH

    2. A CODEX_CLI_PATH entry under [mcp_servers.node_repl.env] in:
      C:\Users\ZXY\.codex�nfig.toml

    After removing both overrides and restarting all Codex-related processes, Codex Desktop started the bundled CLI correctly:

    C:\Program Files\WindowsApps\OpenAI.Codex_26.616.4196.0_x64__2p2nqsd0c76g0�pp esources�dex.exe

    The thread/start request then completed successfully, and the PermissionProfileSelectionParams error disappeared.

    So this was caused by a local stale CLI path override rather than a Codex Desktop bug. Closing as resolved.

  3. VectorPeak commented on Jun 20, 2026

    @VectorPeak
    Author

    Closing as resolved. Root cause was a stale local CODEX_CLI_PATH override that forced Codex Desktop to launch an older CLI/app-server, causing a frontend/backend protocol mismatch.

  4. derekroetzel commented on Jun 22, 2026

    @derekroetzel

    @VectorPeak Thank you for this. I had the same issue, and this helped me solve it quickly.

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

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions