Skip to content

Codex Desktop auto-declines OpenAI Developers API-key destination elicitation #30978

New issue
New issue
Open
Open
Codex Desktop auto-declines OpenAI Developers API-key destination elicitation#30978
Labels
appIssues related to the Codex desktop appbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) servers

Description

@johnsilvavlogs
johnsilvavlogs
opened on Jul 3, 2026

What variant of Codex are you using?

Codex Desktop macOS.

  • GUI app version: 26.623.81905, build 4598
  • App-bundled CLI: codex-cli 0.142.5
  • Global CLI: codex-cli 0.142.1
  • Plugin: openai-developers@openai-curated-remote version 1.2.3
  • MCP server: openai-api-key-local-confirmation
  • Tool: confirm_openai_api_key_local_destination

What issue are you seeing?

The OpenAI Developers plugin's local API key destination confirmation cannot be accepted in Codex Desktop. The MCP server requests a form-mode elicitation/create with a required targetPath, but the live Desktop client immediately returns action: "decline" instead of rendering an accept/edit confirmation form.

That blocks the secure API-key setup flow because the plugin correctly refuses to create or write a key unless this local destination confirmation returns approved.

Steps to reproduce

  1. In Codex Desktop, use the OpenAI Developers plugin API-key setup flow.
  2. Select an OpenAI Platform key target successfully.
  3. Call the local destination confirmation tool with arguments like:
{
  "workspacePath": "/path/to/workspace",
  "targetPath": ".env.local",
  "envName": "OPENAI_API_KEY"
}
  1. The MCP server sends an elicitation request equivalent to:
{
  "method": "elicitation/create",
  "params": {
    "mode": "form",
    "message": "Choose where OpenAI Developers should save the new API key as OPENAI_API_KEY.",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "targetPath": {
          "type": "string",
          "title": "Save location",
          "default": "/path/to/workspace/.env.local",
          "minLength": 1
        }
      },
      "required": ["targetPath"]
    }
  }
}
  1. Codex Desktop immediately returns a declined result. The observed tool output is:
{
  "status": "not_approved",
  "action": "decline"
}

Observed timing was ~16ms, and no usable accept/edit prompt appeared in the thread UI. The behavior repeated across multiple attempts, including after explicitly invoking the OpenAI Developers plugin in the thread.

Expected behavior

Codex Desktop should render the form-mode elicitation and allow the user to accept or edit the target path. For the default path above, the MCP server expects a response like:

{
  "action": "accept",
  "content": {
    "targetPath": "/path/to/workspace/.env.local"
  }
}

If Desktop cannot render the elicitation, it should surface a clear client/UI error instead of returning decline, because decline is treated as an intentional user refusal and safely blocks key creation.

Diagnostics already checked

  • The OpenAI Platform connector is authenticated and can list the exact org/project target.
  • The local destination is repo-safe: .env.local exists, is git-ignored, and is not tracked.
  • The plugin's local tests pass:
node --test .../openai-developers/1.2.3/tests/openai-platform-api-key.test.mjs
# pass 28, fail 0, skipped 2

Those tests include:

  • local destination confirmation accepts an override
  • local destination confirmation stops when developer cancels
  • decrypt writes/updates the API key without printing it
  • decrypt rejects symlink/hardlink/out-of-workspace targets

So the plugin server/helper paths appear functional; the live failure is in the Desktop client's handling/rendering of the form elicitation.

Related issue

Possibly related to, but not identical with, #23383. That issue covers auto-approve returning accept with {} for required schemas. This report is the opposite user-visible failure mode: the required form elicitation is immediately returned as decline and the user never gets a working approval path.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    mcpIssues related to the use of model context protocol (MCP) servers
    on Jul 3, 2026

  2. maxanatsko commented on Aug 12, 2026

    @maxanatsko
    maxanatsko
    on Aug 12, 2026

    Additional exact reproduction from an independent third-party MCP server on Windows:

    • Codex Desktop 26.803.10989.0 (Windows ARM64), embedded MCP client codex-mcp-client 0.147.0-alpha.6.6
    • The server sent a standard form-mode elicitation/create containing one required boolean confirmation field
    • The parsed response was Decline after 37 ms
    • No elicitation UI appeared
    • The behavior reproduced across multiple confirmation attempts

    This confirms the failure is not specific to the OpenAI Developers plugin or a string-input schema: Codex Desktop also immediately declines a required boolean form elicitation from another MCP server.

  3. alex123321-maker commented on Oct 30, 2026

    @alex123321-maker
    alex123321-maker
    on Oct 30, 2026 – with ChatGPT Codex Connector

    Confirmed a related reproduction on Windows on 2026-10-30, with a successful permissions-policy workaround. Posted by Codex at the user's explicit request.

    Environment:

    • Windows x64; installed desktop package version 26.1027.3384.0 (package version, not independently checked against the About dialog).
    • openai-developers@openai-curated-remote version 1.3.13.
    • Local MCP server openai-api-key-local-confirmation.

    Reproduction and observed results:

    1. Run the plugin's setup skill in a desktop chat with approval_policy=never and sandbox_mode=danger-full-access.
    2. Call choose_openai_api_key_setup({}).
    3. No form appears. Repeated calls immediately return {"status":"not_selected"} with No API key setup choice was confirmed. The user explicitly confirmed that no form appeared; they did not cancel it.
    4. Opening the OpenAI Developers dashboard succeeds, but retrying the local setup form still produces the same result.
    5. The user changed the chat permission profile. The subsequent effective policy was granular with mcp_elicitations=true (sandbox changed to workspace-write).
    6. The same tool then displayed the form and returned {"status":"selected","choice":"create"} after the user's selection. The subsequent confirm_openai_api_key_local_destination form also displayed and returned approved; secure key creation and local saving completed.

    The local MCP startup logs show the server reaching ready, so this was not a missing executable or non-default installation-path failure.

    Read-only static inspection suggests a capability/policy mismatch: the installed desktop initialization code advertises OpenAI form elicitation, but no literal openai/standard-form-input declaration was found in the inspected application JavaScript. Current upstream codex-mcp/src/elicitation.rs declines under AskForApproval::Never unless the Full Access form-input exception applies, and core/src/thread_manager.rs enables that exception for the standard-form-input extension. This is supporting evidence, not a captured wire-level trace or proof that current main exactly matches the installed binary. Also, the UI profile change affected both approval policy and sandbox mode, so it was not a strictly single-variable experiment.

    Expected: show required user-input forms through the supported desktop flow, or clearly explain that the permission policy blocked the form. Returning a result indistinguishable from user cancellation makes onboarding repeatedly ask the user to retry a dialog they never saw.

    No API keys, account/org/project identifiers, local user paths, or raw session logs are included.

  4. curranmichael commented on Nov 3, 2026

    @curranmichael
    curranmichael
    on Nov 3, 2026 – with ChatGPT Codex Connector

    Additional reproduction on 2026-11-03 in the ChatGPT desktop app / Work with a local project. Posted by the assistant at the user's explicit request.

    Environment

    • App bundle: ChatGPT, bundle ID com.openai.codex, version 26.1027.61615, build 24141 (read from the installed Info.plist).
    • Bundled executable: codex-cli 0.166.0-alpha.5.1.
    • macOS 27.2, build 26B123.
    • Installed OpenAI Developers plugin: 1.3.13.
    • Session permissions: workspace-write, granular approval policy, with mcp_elicitations enabled.

    Reproduction

    1. User invokes OpenAI Developers with the provided prompt: “Create a project API key to use in this project.”
    2. The plugin's instructions recommend open_codex_api_key_setup, but that tool is absent from the tools exposed to this session. The encrypted-key creation tool and local-destination tool are available.
    3. Following the documented fallback for an unavailable picker, call confirm_openai_api_key_local_destination with a valid absolute workspace path, targetPath: "gateway/.env.local", and envName: "OPENAI_API_KEY". The target is inside the workspace and covered by its env-file ignore pattern.
    4. The result is:
    {
  "status": "not_approved",
  "action": "decline"
}

    The accompanying text is: “The local API key destination was not approved. Do not create or write a key.”

    1. After the user questioned this and reiterated that this is OpenAI's official prompt, retrying produced exactly the same result. Each surrounding tool execution completed in approximately 0.3 seconds. These timings are tool-wrapper observations, not wire-level elicitation latency.

    No affirmative destination selection was made in the conversation. The assistant initially characterized this as a declined confirmation, which was misleading: the response does not distinguish a user decision from an automatically generated decline. The user continued to request that the official setup flow work.

    Diagnostics

    • Read-only inspection of plugin mcp/server.mjs shows that the destination handler requests a form with a required targetPath. It reports not_approved when the elicitation response's action is not accept, forwarding that action. It does not independently classify a valid destination as declined.
    • Ran the installed plugin tests filtered to local destination confirmation|shared calls bind: 5 passed, 0 failed. These cover accepting an edited destination, rejecting an out-of-workspace destination, cancellation, binding shared approval to its original call, and instruction coverage. They validate the server logic, not the desktop UI.
    • The Oct 30 workaround above changed the session to granular approvals with MCP elicitations enabled. This session already exposes that configuration, so the earlier approval_policy=never explanation is insufficient for this reproduction.
    • The exact lower-level client/host branch generating the decline has not been isolated. No wire-level trace establishes it. The missing project picker is a separate observed setup-flow availability problem.

    Requested behavior

    The supported OpenAI Developers flow should expose its project picker and display the save-location form, waiting for the user's answer. If the client cannot deliver the form, it should return an explicit unavailable/policy/transport error rather than an indistinguishable user decline. Please also test the Work/local-project tool bridge, in addition to native Codex chats.

    No API key was created or written. This comment omits account identifiers, personal filesystem paths, secrets, and raw session logs.

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 appbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) servers

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions