Skip to content

Codex Desktop omits codex_app project/thread tools with a custom Responses provider #37075

Open
Open
Codex Desktop omits codex_app project/thread tools with a custom Responses provider#37075
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingcustom-modelIssues related to custom model providers (including local models)

Description

@heyarny
heyarny
opened on Aug 5, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

ChatGPT/Codex Desktop 26.730.61639 (build 6234)

Bundled runtime: codex-cli 0.147.0-alpha.1.2

What subscription do you have?

Custom OpenAI-compatible provider authenticated through env_key; no OpenAI login is active (codex login status reports Not logged in).

What platform is your computer?

Darwin 25.6.0 arm64 arm
macOS 26.6 (build 25G72)

What issue are you seeing?

Fresh local Codex Desktop tasks using a custom Responses API provider do not receive the first-party codex_app project/thread-management tools.

The task exposes only these codex_app tools:

codex_app__automation_update
codex_app__load_workspace_dependencies
codex_app__navigate_to_codex_page
codex_app__read_thread_terminal

The project/thread-management group is absent, including:

codex_app__list_projects
codex_app__list_threads
codex_app__read_thread
codex_app__create_thread
codex_app__send_message_to_thread
codex_app__fork_thread
codex_app__set_thread_title
codex_app__set_thread_archived

There is also no usable tool_search path for discovering these tools. This is not a call-time failure: the functions are missing from the task's tool manifest, so the assistant cannot invoke them at all.

The failure persists after fully quitting and restarting the Desktop app and creating a brand-new task. It is specific to the custom-provider path: on the same machine and Desktop app, switching to the built-in OpenAI provider with a ChatGPT account makes the project/thread-management tools available again. The missing capabilities are first-party Desktop task APIs, not APIs served by the custom model provider.

Sanitized provider configuration:

model = "gpt-5.6-sol"
model_provider = "company_proxy"

[model_providers.company_proxy]
name = "Company OpenAI-compatible proxy"
env_key = "CUSTOM_PROVIDER_API_KEY"
base_url = "https://<company-openai-compatible-proxy>/<redacted>/v1"
wire_api = "responses"

The provider successfully handles normal model responses and other tools. The problem is limited to exposure of the Desktop project/thread-management tool group.

What steps can reproduce the bug?

  1. Configure a non-OpenAI, OpenAI-compatible Responses provider using model_providers.<id>, env_key, and wire_api = "responses".

  2. Select gpt-5.6-sol and the custom provider at the top level of ~/.codex/config.toml.

  3. Fully quit and reopen the ChatGPT/Codex Desktop app.

  4. Create a brand-new local Codex task.

  5. Ask:

    List my saved Codex projects and their latest threads. Use the Codex app
project and thread-management tools.

  6. Inspect the available tool surface or attempt to use codex_app__list_projects, codex_app__list_threads, or codex_app__read_thread.

Actual result: none of those functions are present. Only the four non-thread-management codex_app tools listed above are exposed.

Control comparison:

  1. Use the same Desktop app and machine with the built-in OpenAI provider and a ChatGPT account.
  2. Create a fresh task and repeat the prompt.

Control result: the codex_app project/thread-management tools are available. The provider/auth combination is the observed difference.

Original affected task session ID: 019fd146-6c22-71b2-91c6-cf7c92702e7c

What is the expected behavior?

Codex Desktop should expose its first-party project/thread-management tools independently of which compatible model provider generates the assistant response.

At minimum, a fresh Desktop task should receive list_projects, list_threads, read_thread, create_thread, and send_message_to_thread when the host supports those operations. If the active provider is intentionally incompatible, the app should show a clear provider-capability diagnostic instead of silently omitting the tools while installed skills and app guidance still reference them.

Additional information

This resembles several existing reports, but this reproduction combines the current Desktop build, a custom Responses provider, and the first-party project/thread-management tool group:

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    app-serverIssues involving app server protocol or interfaces
    custom-modelIssues related to custom model providers (including local models)
    on Aug 5, 2026

  2. k421s commented on Aug 6, 2026

    @k421s
    k421s
    on Aug 6, 2026

    Independent reproduction with DeepSeek (2026-08-05)

    Same build and symptom reproduced with the DeepSeek official custom provider (deepseek-v4-flash, wire_api = "responses", API-key auth, no OpenAI login). Session rollout 019fd492-b9b3-7163-abae-0b910f1f8c58 shows the thread tools ARE registered in dynamic_tools, but only in the deferred group:

    • deferLoading: true: automation_update, fork_thread, handoff_thread, get_handoff_status, list_projects, create_thread, list_threads, read_thread, wait_threads, send_message_to_thread, set_thread_pinned, set_thread_archived, set_thread_title
    • direct (visible): navigate_to_codex_page, read_thread_terminal, load_workspace_dependencies

    The captured Responses request to DeepSeek includes {"type":"tool_search",...} plus those three direct tools, but not the deferred thread tools. deepseek-v4-flash does not invoke tool_search, so the deferred group is unreachable — same behavior documented in https://github.com/CCanxue/codex-deepseek-subagent-fix for v1 multi-agent tools.

    So the practical gap here is not "the app never registered the tools" — it registered them and then hid them behind a discovery mechanism the custom model won't call. This matches the related #36382/#31750 family.

    Suggested fix direction (any one would unblock):

    1. Do not defer first-party codex_app thread tools when the active provider/model cannot use tool_search; expose them directly.
    2. Treat thread_tools as provider-independent instead of tied to the Statsig userID-gated feature flag (local Sentry scope shows gate 2395575782 cannot evaluate without a userID).
    3. Add the namespace_tools = false / flatten escape requested in MCP tools silently unavailable with llama-server backends — add option to flatten namespace tool specs to functions #36942 so custom-provider sessions can opt into plain function tools.

    Full lab write-up: https://github.com/k421o/codex-deepseek-labs/issues/4

  3. heyarny commented on Aug 26, 2026

    @heyarny
    heyarny
    on Aug 26, 2026
    Author

    As of version Version 26.820.60940 on MacOS the tools seem to be available again.

    Descriptions are concise paraphrases, not the internal manifest text.

    Core execution

    • functions.exec — Runs JavaScript that can coordinate nested tools.
    • functions.wait — Waits for a previously yielded execution to produce more output.
    • functions.request_user_input — Presents structured questions to the user; Plan mode only.

    Shell and files

    • exec_command — Runs a shell command in a managed terminal.
    • write_stdin — Sends input to or polls an active terminal session.
    • apply_patch — Creates or edits files using a patch.
    • view_image — Loads a local image for visual inspection.

    Planning and goals

    • update_plan — Creates or updates a step-by-step task plan.
    • create_goal — Starts an explicitly requested tracked goal.
    • get_goal — Reads the active goal’s status and usage.
    • update_goal — Marks an active goal complete or blocked.

    MCP resources

    • list_mcp_resources — Lists static resources exposed by MCP servers.
    • list_mcp_resource_templates — Lists parameterized MCP resource templates.
    • read_mcp_resource — Reads a selected MCP resource.

    Codex tasks and projects

    • list_projects — Lists available local, remote, and ChatGPT projects.
    • list_threads — Lists recent and pinned Codex tasks.
    • list_archived_threads — Lists archived tasks.
    • read_thread — Reads another task’s recent status and messages.
    • create_thread — Creates a separate user-owned task.
    • fork_thread — Forks an existing task and its history.
    • send_message_to_thread — Sends a follow-up prompt to another task.
    • wait_threads — Waits for one or more tasks to finish or require attention.
    • handoff_thread — Moves a task and its Git state between environments or hosts.
    • get_handoff_status — Checks a task-handoff operation.
    • navigate_to_codex_page — Opens a selected task in the main Codex window.
    • set_thread_title — Renames a task.
    • set_thread_pinned — Pins or unpins a task.
    • set_thread_archived — Archives or restores a task.

    Codex workspace and UI

    • load_workspace_dependencies — Locates bundled runtimes and document-processing libraries.
    • open_in_codex — Opens a file, terminal, browser tab, or code review in a Codex panel.
    • read_thread_terminal — Reads this task’s current terminal output.

    Automations

    • automation_update — Creates, views, updates, pauses, or deletes scheduled automations and heartbeats.

    Internal agent coordination

    • spawn_agent — Starts a sub-agent on a delegated subtask.
    • followup_task — Assigns another turn to an existing agent.
    • send_message — Sends information to a running agent without starting a new turn.
    • wait_agent — Waits for an agent to finish or report progress.
    • interrupt_agent — Stops or redirects an agent.
    • list_agents — Lists agents and their current states.
  4. heyarny
    closed this as completedon Aug 26, 2026
  5. heyarny
    reopened this on Sep 23, 2026

  6. heyarny commented on Sep 23, 2026

    @heyarny
    heyarny
    on Sep 23, 2026
    Author

    Reopening: the tool-availability regression returned several app versions before the current ChatGPT/Codex Desktop 26.917.62051 (build 10789, production). The app reports this build as up to date. To reproduce, set a custom provider (for example, Azure) and start a fresh task: the tools disappear.

  7. heyarny commented on Oct 5, 2026

    @heyarny
    heyarny
    on Oct 5, 2026
    Author

    Now with the version of 26.930.51102 the list got even worse.

    apply_patch
clock.sleep
clock__curr_time
collaboration.followup_task
collaboration.interrupt_agent
collaboration.list_agents
collaboration.send_message
collaboration.spawn_agent
collaboration.wait_agent
create_goal
exec_command
functions.exec
functions.request_user_input
functions.request_user_input_async
functions.wait
get_goal
list_mcp_resource_templates
list_mcp_resources
mcp__openaiDeveloperDocs__fetch_openai_doc
mcp__openaiDeveloperDocs__get_openapi_spec
mcp__openaiDeveloperDocs__list_api_endpoints
mcp__openaiDeveloperDocs__list_openai_docs
mcp__openaiDeveloperDocs__search_openai_docs
read_mcp_resource
update_goal
view_image
write_stdin

    Not a single codex app tool available.

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 workingcustom-modelIssues related to custom model providers (including local models)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions