[Bug/UX]: Claude Desktop “Save and apply” silently replaces the native model catalog and lacks a safe restore path

[str0203]

Client or integration

Claude Desktop 3P profile

Area

Claude Desktop integration · Dashboard / configuration UX

Summary

Applying an OpenCodex Claude Desktop profile through Claude → Desktop → Save and apply silently replaces Claude Desktop's native first-party model catalog instead of adding routed models alongside it.

Before applying the profile, the Desktop picker contains the user's normal Claude subscription models (for example Fable 5, Opus 5, Sonnet 5, and Haiku 4.5). After applying, those entries disappear and the picker contains only the static OpenCodex gateway models.

The user reasonably interprets “Save and apply” as enabling the selected OpenCodex routes, not as replacing the entire native catalog. The UI currently provides no prominent destructive-effect warning and no one-click “Restore native Claude configuration” action.

Even if native first-party and gateway catalogs cannot technically coexist in the current Claude Desktop configuration model, OpenCodex should make that limitation explicit and make the operation safely reversible.

Reproduction

1. Start with Claude Desktop signed in normally and confirm its native models are visible.
2. Configure several routed models in OpenCodex.
3. Open the OpenCodex dashboard.
4. Go to Claude → Desktop and assign routed models to the Opus/Fable/Sonnet/Haiku families.
5. Click Save and apply.
6. Fully quit and reopen Claude Desktop.
7. Open the model picker.

Actual behavior

The native Claude models disappear. The applied configuration has this effective shape:

{
  "inferenceProvider": "gateway",
  "modelDiscoveryEnabled": false,
  "inferenceModels": ["OpenCodex-generated static entries"]
}

The config library metadata selects only the OpenCodex entry:

{
  "appliedId": "<opencodex-config-id>",
  "entries": [
    {
      "id": "<opencodex-config-id>",
      "name": "opencodex"
    }
  ]
}

There is no visible restore action in OpenCodex. In addition, once claudeCode.desktopProfile exists, desktopAutoApply defaults to enabled and provider changes can reapply the profile in static mode, so manually reverting the Desktop config can be undone later.

Expected behavior

At minimum:

1. Before applying, show an explicit warning such as:

   This switches Claude Desktop to the OpenCodex gateway and replaces the native Claude model catalog. It does not add models alongside your existing Claude subscription models.

2. Require explicit confirmation for the replacement.
3. Preserve enough prior applied-state metadata to offer a reliable Restore native Claude configuration action.
4. Provide a CLI equivalent for restore/unapply.
5. Do not silently auto-reapply a static Desktop profile after the user restores the native configuration.
6. Clearly explain what static, hybrid, and discovery-only do, including that hybrid does not necessarily merge the first-party Claude subscription catalog.

Ideally, if technically possible, provide a supported profile-switching or native-passthrough design that lets users access native Claude models and routed OpenCodex models without losing either catalog. If Claude Desktop's single-provider model makes this impossible, the UI should say so rather than implying additive model installation.

Technical evidence

Current implementation defaults to static mode:

• parseDesktop3pModeArgs() returns static when no mode flag is supplied.
• generateDesktop3pConfig() sets inferenceProvider: "gateway".
• Static mode sets modelDiscoveryEnabled: false and writes a complete inferenceModels list.
• autoApplyDesktopBestEffort() also calls writeDesktop3pConfig(..., "static", ...).

The source comment itself notes that the static list “OVERRIDES discovery (no merge).”

Environment

• OpenCodex: 2.8.0
• OS: macOS
• Claude client: Claude Desktop app
• OpenCodex Claude auth mode: subscription
• Example routed models: DeepSeek, GPT, and an OpenAI-compatible relay model

Impact

This is surprising and potentially disruptive for subscription users:

• Their expected native models disappear.
• They may believe their Claude subscription or account access is broken.
• Reverting is not discoverable.
• Auto-apply can restore the unwanted gateway configuration later.
• Users must understand undocumented internal files such as Claude-3p/configLibrary/_meta.json to recover.

Checks

• Searched existing issues for native models disappearing, catalog replacement, static override, and native/routed merge behavior.
• Removed credentials, account identifiers, and personal data.
• Reproduced from the generated Desktop configuration and current source behavior.

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[github-actions]

Maintainer decision respected

A maintainer has reopened this issue. The automated closure has been deactivated.

[str0203]

Follow-up enhancement proposal: Additive Claude Desktop catalog mode

The ideal user experience is not merely a safer replacement flow. Users want to keep their existing Claude models and add selected OpenCodex routes to the same picker.

Feasibility boundary

There appear to be two materially different meanings of “native + routed models”:

1. True first-party coexistence

Claude Desktop keeps its existing first-party subscription models and credentials, while OpenCodex adds extra model routes.

This does not appear implementable through the current OpenCodex Desktop writer alone:

• Claude Desktop serves only the configuration selected by one configLibrary/_meta.json.appliedId.
• The generated OpenCodex config selects one inferenceProvider: "gateway".
• OpenCodex currently sets inferenceCredentialKind: "static" and supplies a gateway key.
• Consequently, the Desktop's first-party subscription credential is not necessarily sent to the gateway.
• Adding official-looking claude-* rows to inferenceModels is not sufficient if the gateway cannot receive or safely resolve the user's original first-party credential.

If Claude Desktop exposes a supported credential-passthrough or multi-provider mechanism, OpenCodex could use it. Otherwise, this part should be documented as an upstream limitation rather than simulated unsafely.

2. Unified gateway catalog (implementable approximation)

OpenCodex can potentially expose one combined gateway catalog containing:

• selected routed OpenCodex models; and
• genuine Claude models routed through an explicitly configured OpenCodex Anthropic OAuth/API credential.

This would produce the desired combined picker, although the Claude entries would be gateway-routed rather than the untouched first-party Desktop provider.

This mode must clearly disclose credential and billing provenance. It must never silently turn a Claude subscription model into separately billed Anthropic API traffic.

Proposed modes

The Desktop page could offer an explicit mode selector:

Native Claude
  Do not apply an OpenCodex inference profile.

Additive / unified gateway
  Show Claude-family routes and selected OpenCodex routes together.
  Requires a usable Anthropic credential managed by OpenCodex.
  Clearly labels which credential/provider serves each model.

OpenCodex only
  Replace the picker with the selected OpenCodex routes (current static behavior).

If true additive mode is not possible, provide a supported profile-switching fallback:

Use native Claude configuration
Use OpenCodex configuration

Switching must preserve both profiles and require only one click, without editing _meta.json manually.

Suggested implementation investigation

1. Probe whether current Claude Desktop can forward first-party OAuth while using a gateway base URL.
2. If supported, add official Claude IDs to the same generated catalog and use the existing native-passthrough path.
3. If not supported, implement unified gateway mode only when an explicit Anthropic credential is configured.
4. Preserve the previous applied configuration and expose restore/switch actions.
5. Store the selected Desktop mode and stop autoApplyDesktopBestEffort() from always rewriting it as static.
6. Add provenance labels such as:
   • Claude Opus 5 · native passthrough
   • Claude Opus 5 · Anthropic OAuth via OpenCodex
   • GPT 5.6 Sol · ChatGPT pool via OpenCodex

Acceptance criteria

• Applying an additive mode does not silently remove expected Claude-family access.
• The UI accurately distinguishes first-party passthrough from OpenCodex-managed Anthropic OAuth/API access.
• No silent credential substitution or separately billed API fallback occurs.
• The exact request model ID remains stable.
• Native/OpenCodex profile switching is reversible and survives restarts.
• If the installed Claude Desktop version cannot support coexistence, the UI explains the limitation before applying anything.

This would turn the current destructive replacement workflow into either real coexistence where supported, or an honest and reversible approximation where it is not.