Skip to content

Claude Desktop footer model picker does not update the active 3P conversation model #603

Closed as not planned

Description

@staavanothanh

Client or integration

Claude Code

Area

Other

Summary

Bug: Claude Desktop footer model picker does not update the active 3P conversation model

Summary

When using Claude Desktop through OpenCodex 3P gateway mode, the footer model picker displays multiple configured models, but switching to another model does not update the model used by the active conversation.

The conversation continues using the model selected when the worker process was initially created.

Claude Code CLI and the Claude Code VS Code extension do not have this problem. Their /model switching works correctly.

Reproduction

Bug: Claude Desktop footer model picker does not update the active 3P conversation model

Environment

  • OS: Windows 11
  • OpenCodex version: 2.7.42
  • Claude Desktop version: 1.24012.9
  • Embedded Claude Code worker version: 2.1.219
  • OpenCodex gateway: http://127.0.0.1:10100
  • Integration mode: Claude Desktop 3P gateway
  • Provider: OpenAI native / ChatGPT Codex account
  • Test route: native/gpt-5.6-sol

Model configuration

The following model is configured through OpenCodex:

Field Value
Display name GPT-5.6 Sol
Provider OpenAI native
OpenCodex route native/gpt-5.6-sol
Claude Desktop alias claude-opus-4-8-20260304
Gateway http://127.0.0.1:10100

The Claude Desktop alias is the synthetic alias generated by OpenCodex for the Desktop 3P model catalog.

Reproduction steps

  1. Start OpenCodex:

    ocx start
  2. Verify the Desktop profile:

    ocx claude desktop show --json
  3. Open Claude Desktop.

  4. Create a new 3P conversation.

  5. Select the following model from the Claude Desktop footer picker:

    GPT-5.6 Sol
    
  6. Send a prompt:

    Hello, identify the model currently serving this request.
    
  7. Confirm that the OpenCodex log shows the expected OpenAI/GPT route.

  8. Switch the footer picker to another configured model, for example:

    oc/deepseek-v4-flash-free
    
  9. Send another prompt:

    Hello again. Identify the model currently serving this request.
    
  10. Switch back to:

GPT-5.6 Sol
  1. Send another prompt and inspect the OpenCodex request log.

Actual behavior

The footer picker changes visually, but the active conversation continues sending requests with the model that was selected when the worker was launched.

The embedded worker process contains a fixed model argument similar to:

claude.exe ... --model claude-opus-4-8-20260304

After switching the footer model, the worker process is not restarted and its --model argument is not updated.

Example OpenCodex log:

requestedModel = native/gpt-5.6-sol
resolvedModel  = gpt-5.6-sol
provider       = openai
status         = 200

After switching the footer picker to another model, the request still shows:

requestedModel = native/gpt-5.6-sol
resolvedModel  = gpt-5.6-sol
provider       = openai
status         = 200

The selected model in the Claude Desktop UI and the model actually used by the gateway are therefore inconsistent.

Expected behavior

When the user changes the model in the Claude Desktop footer picker, one of the following should happen:

  1. Claude Desktop sends the new model alias in the next request; or
  2. Claude Desktop restarts/reconfigures the embedded worker with the new model; or
  3. The UI clearly indicates that model changes only apply to new conversations.

For example, after selecting:

GPT-5.6 Sol

the request should use:

native/gpt-5.6-sol

After selecting:

oc/deepseek-v4-flash-free

the next request should use:

9router/oc/deepseek-v4-flash-free

Comparison with other integrations

The same OpenCodex configuration works correctly with:

  • Claude Code CLI
  • Claude Code VS Code extension

In those integrations, /model or the native model picker updates the model used for subsequent requests.

The issue appears specific to the Claude Desktop 3P integration and its footer picker.

Workaround

Using the following command inside the active conversation may change the model:

/model claude-opus-4-8-20260304

However, the footer picker itself does not reliably update the running conversation.

Creating a new conversation after selecting a model also appears to initialize the worker with the selected model.

Diagnostic information

OpenCodex version:

opencodex 2.7.42

Desktop profile summary:

{
  "defaultRoute": "native/gpt-5.6-sol",
  "desktopAlias": "claude-opus-4-8-20260304",
  "gateway": "http://127.0.0.1:10100"
}

Embedded worker command line:

claude.exe ... --model claude-opus-4-8-20260304

Relevant request log:

{
  "surface": "claude-desktop",
  "provider": "openai",
  "requestedModel": "native/gpt-5.6-sol",
  "resolvedModel": "gpt-5.6-sol",
  "status": 200
}

### Version

2.7.42

### Operating system

Windows 11

### Provider and model

OpenAI/GPT-5.6 Sol

### Logs or error output

```shell

Screenshots and supporting files

No response

Redacted configuration

Checks

  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.

Activity

  1. github-actions commented on Jul 28, 2026

    @github-actions
    Contributor

    Automated translation bookkeeping — detected language: English.

  2. github-actions commented on Jul 28, 2026

    @github-actions
    Contributor

    Issue closed: insufficient detail

    Thanks for taking the time to submit this issue. It was closed automatically because the structured report is missing information needed to evaluate or reproduce it.

    • Summary and Reproduction contain the same content.

    Please edit the issue to add:

    • Summary should describe the symptom; Reproduction should list the exact steps.

    See the Contributing guide for details.

    Once the report passes the automated checks, it will be reopened automatically unless a maintainer has changed its state.

  3. ZhenyuXiao commented on Sep 6, 2026

    @ZhenyuXiao

    I am encountering the same symptom on Windows, with one additional problem: the documented /model <id> workaround does not work for me either.

    Environment

    • OpenCodex: 2.43.0 (verified locally)
    • OS: Windows
    • Client: Claude Desktop using the OpenCodex third-party gateway profile
    • Catalog: 16 configured routes; selecting a model when starting a conversation works
    • Comparison: model switching works in Claude Code with OpenCodex
    • Exact Claude Desktop version: not yet collected

    Steps to reproduce

    1. Configure and apply a Claude Desktop profile containing multiple OpenCodex model routes.
    2. Open Claude Desktop, select model A, and start a conversation. Responses work.
    3. In that same conversation, select model B using the model picker and continue chatting.
    4. Try /model <model-B-desktop-alias> in the same conversation as suggested by the OpenCodex documentation.
    5. Compare with Claude Code, where switching models works.

    Observed behavior

    I cannot switch the model within the existing Claude Desktop conversation, either through the picker or through /model. Initial model selection works, so the problem is specifically switching within an existing conversation.

    This is a user-observed reproduction. I have not yet captured a controlled before/after request-log comparison, so I am not claiming to have independently confirmed whether Desktop keeps sending the original model ID or OpenCodex resolves a changed ID incorrectly.

    Expected behavior / questions

    The next turn should use the newly selected model while preserving the conversation history.

    • Is there a supported workaround for Claude Desktop when both the picker and /model fail?
    • Does the documented /model workaround apply only to particular Desktop versions or surfaces (Chat, Code, or Cowork)?
    • Is there a newer fix or an upstream Anthropic issue tracking this behavior?
    • Which sanitized diagnostics would be most useful to distinguish a Desktop request-model problem from an OpenCodex routing problem?

    Related report: #546. Documentation: https://opencodex.me/guides/claude-code/

    I noticed this issue was automatically closed for report-format reasons. Could this additional reproduction be considered for continued investigation, or should it be filed as a separate issue?

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 working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions