Skip to content

[Windows Desktop] fresh and resumed Tasks omit codex_app capability root #46653

Open
Open
[Windows Desktop] fresh and resumed Tasks omit codex_app capability root#46653
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@DavidPrvni
DavidPrvni
opened on Sep 19, 2026

Codex version

OpenAI.Codex Desktop package 26.915.4065.0; embedded/running runtime 0.155.0-alpha.9.2; ChatGPT.exe ProductVersion 153.0.8010.48.

Subscription

ChatGPT account using Codex Desktop (account identifiers intentionally omitted).

Platform

Windows 11 Home 10.0.26200 build 26200.

What happened?

Native Codex Desktop Task-management tools are absent from the model-visible tool catalog in both a newly started project Task and a resumed Task. Missing operations include create_thread, list_threads, read_thread, wait_threads, handoff_thread, send_message_to_thread, set_thread_title, set_thread_archived, and sidebar/pinning operations.

This appears to be a Desktop capability-root/executor-metadata provisioning regression, not a missing provider or broken backend API.

Steps to reproduce

  1. Open Codex Desktop on Windows.
  2. Start a new Task over a saved project, or resume an existing Task.
  3. Inspect the actual tool catalog available to the Task.
  4. Observe that no native Task-management tools are present.
  5. Inspect app-server telemetry for the corresponding thread/start and world-state spans.

Current fresh Task/session ID: 01a0ba0c-32cc-73a2-be4e-ceb932576681

Affected resumed Task/session ID: 01a0b669-8fdf-7011-b764-63299079ee22

Expected behavior

Desktop should inject the native codex_app capability root plus executor thread metadata into both fresh and resumed Tasks. The Task should receive the native thread-management catalog and be able to call list/read/wait/create/handoff operations subject to their normal guards.

Actual behavior

Sanitized evidence:

current fresh Task thread/start: thread_start.dynamic_tool_count=0
current fresh Task world state: selected_capability_root_count=0
affected resumed Task world state: selected_capability_root_count=0
other newly started Tasks: thread_start.dynamic_tool_count=0

The current runtime's generated protocol schema includes thread/start.dynamicTools and thread/start.selectedCapabilityRoots, with capability roots described as selected by the hosting platform.

The packaged and running codex.exe are identical:

SHA-256 BC45017E8239DC150258F69309CED9DF6BBCDF5B8E4F346DECF780AC0999E226

A read-only diagnostic launch of the bundled codex-app-tools provider returned 44 tools, including every missing Task-management operation. Calling list_threads without executor metadata produced:

Codex app tools require thread metadata from the executor.

Adding MCP _meta.threadId for the current Task made list_threads succeed. read_thread and wait_threads(timeoutMs=0) also succeeded for the affected Task. No mutating provider operation was invoked. This confirms that the Desktop pipe/provider and backend Task APIs are healthy; the failure occurs in host-to-app-server capability injection.

The current Desktop instance's text log files are zero bytes, but the read-only app-server telemetry database contains the spans above. No raw database/session file is attached to avoid account and path disclosure.

Scope and safety

  • Reproduces in both a fresh project Task and a resumed Task, so it is not resume-only persisted state.
  • Repeated Desktop restarts and updates did not repair it.
  • SQLite databases and session JSONL were read only.
  • No cache/history/Tasks/worktrees/login state were deleted or reset.
  • No config, feature flag, repository, plugin state, or application data was modified.

Related issues / release note

The official changelog lists Refresh resumed thread capability roots from executors (#39746). The current behavior may be a regression or a broader Windows provisioning failure.

Closest open reports found were #43350 (macOS delegated follow-up loses selected capability roots) and #32436 (new Desktop tasks missing generic workspace tools). This reproduction is different: it affects the native codex_app Task-management capability in ordinary fresh and resumed Windows Tasks, while the provider/backend remains callable.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    app-serverIssues involving app server protocol or interfaces
    on Sep 19, 2026

  2. github-actions commented on Sep 19, 2026

    @github-actions
    github-actionsbot
    on Sep 19, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. Ayyiyo commented on Oct 2, 2026

    @Ayyiyo
    Ayyiyo
    on Oct 2, 2026

    I had the same user-visible symptom on Windows — fresh Tasks had zero mcp__codex_app__* thread-management tools — but my failure mode appears to have been different.

    In my case, the bundled codex-app-tools 0.1.5 files were present and Desktop was already passing the codex_app.enabled=true override, but no codex_app MCP child process was running. Restarting the app-server alone did not help.

    I restored the tools by adding an explicit user-level [mcp_servers.codex_app] definition in ~/.codex/config.toml pointing to the installed official bundled codex-app-tools 0.1.5, then restarting the Desktop app-server.

    After that, the native cross-thread tools returned and cross-thread messaging worked again.

    So this may be a separate Windows failure mode rather than the same capability-root injection failure described here. I posted the fuller reproduction and workaround in #49862.

  4. lbai-113 commented on Oct 8, 2026

    @lbai-113
    lbai-113
    on Oct 8, 2026

    I can reproduce the same user-visible failure on Windows.

    Environment:

    • Codex Desktop: 26.1002.7124.0
    • Bundled Codex runtime: 0.162.0-alpha.2
    • Installed through Microsoft Store

    Missing from fresh and existing chats:

    • create_thread
    • list_threads
    • send_message_to_thread
    • handoff_thread
    • wait_threads

    Diagnostics:

    • Restarting and creating a completely fresh chat did not restore the tools.
    • Desktop app-server handshake is healthy.
    • The codex_apps MCP reaches the ready state.
    • Configuration, authentication, networking, and WebSocket checks are healthy.

    The symptom appeared after moving Codex working/state data from C: to D:.
    Rollout/session files remain on disk, but many are not represented in the
    current state index. I cannot confirm that the relocation caused the missing
    capability injection, but it may be relevant.

    Feedback session ID:
    01a11b6f-8698-74e3-95db-da4072282c1f

  5. lbai-113 commented on Oct 8, 2026

    @lbai-113
    lbai-113
    on Oct 8, 2026

    Additional evidence from an older resumed Desktop chat:

    The chat initially reported these tools as available in its tool metadata:

    • list_threads
    • read_thread
    • send_message_to_thread
    • wait_threads
    • handoff_thread

    However, the first real invocation failed:

    codex_app__list_threads({limit: 200})

    Error:
    “This app tool is no longer available through dynamic tools.
    Use the codex_app MCP server.”

    Retrying through mcp__codex_app__list_threads was impossible because that tool
    was not exposed on the host.

    After the failed invocation and capability refresh, the same chat reported that
    all five tools were unavailable.

    This suggests resumed chats may retain stale dynamic-tool metadata even though
    the underlying codex_app MCP capability is not callable.

    Desktop: 26.1002.7124.0
    Bundled runtime: 0.162.0-alpha.2
    Feedback session ID: 01a11b6f-8698-74e3-95db-da4072282c1f

  6. Evren7777 commented on Oct 13, 2026

    @Evren7777
    Evren7777
    on Oct 13, 2026 – with ChatGPT Codex Connector

    补充一例 Windows 本地桌面环境的复现。以下环境信息于 2026-10-12 核验，历史调用记录于 2026-10-13 只读复核。

    环境与实际运行组件

    • Windows 本地桌面应用，PowerShell 工作流。
    • 已安装应用包：OpenAI.Codex 26.1007.2314.0。
    • 启动日志报告实际 app-server：0.162.0-alpha.17.2。
    • 启动选择为 source=copied，使用当前安装包对应的自动复制 CLI。
    • 模型缓存 client_version=0.162.0。这是缓存字段，与上述完整运行版本分别记录。

    工具枚举结果

    原有聊天和由用户手动新建的空白聊天均报告：

    • create_thread：不可见
    • send_message_to_thread：不可见
    • read_thread：不可见
    • wait_threads：不可见
    • handoff_thread：不可见
    • mcp__codex_app__ 前缀：0 个
    • mcp__codex_apps__ 前缀：141 个

    结果来自实际 ALL_TOOLS 元数据枚举，不是因提示词出现了工具名称而推定可用。新空白聊天的结果由用户复制回原聊天；没有使用这些缺失工具创建对照聊天。2026-10-13 原聊天再次枚举，原生命名空间仍为 0。

    已执行的本地排查

    • 已备份并清除用户级 CODEX_CLI_PATH 固定覆盖。
    • 已重启电脑；当前实际运行路径和日志均显示自动复制的新版 CLI。
    • 五个固定运行副本、沙箱 CLI 及对应版本 runner，共七个目标文件的 SHA-256 均匹配当前安装包中的对应源文件。
    • 模型缓存已自动刷新并核验。
    • 本次启动日志中 codex_apps 达到 ready；这仅证明复数连接器服务就绪，不等于单数 codex_app 原生工具存在。
    • 同步组件和新建空白聊天均没有恢复上述五个工具。

    可追溯的历史行为

    同一台电脑的本地会话记录证明：

    • 2026-09-05 至 09-07 曾收到带来源线程 ID 的 codex_delegation 消息。
    • 2026-09-14 曾成功调用 mcp__codex_app__read_thread 并获得另一线程的实际内容。
    • 另有一次 09-11 的发送调用因额度审核被拒绝，未计为成功派发或回传，也未与当前“工具根本不在目录中”的症状混同。
    • 约 09-22 起的旧诊断开始记录新聊天的原生工具缺失；精确失效日期和引入变更仍待核验。

    这些证据证明接口曾实际可用，但没有将某一轮完整自动派发/回传闭环或根因作超出证据的确认。

    请求确认

    1. 这些原生接口目前是否应向此 Windows 本地桌面环境开放？
    2. 是否存在接口迁移、更名、权限/能力开关变化，或 host-to-app-server 工具提供异常？
    3. 请提供受支持的诊断、恢复或替代方式。我们尚未验证本例与 Issue 正文中的 capability-root 机制具有相同根因。

    此前也已通过应用内反馈提交。此公开评论不附完整日志、会话文件、业务资料、账号凭证或本机私有路径。

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 workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions