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

Open 💬 0 comments Opened Jul 3, 2026 by johnsilvavlogs

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.

View original on GitHub ↗