Skip to content

[Desktop Remote SSH 26.825.31414] effectful task tools still missing with CLI 0.150.1 #41248

Open

Description

@shockbladenull

What version of the Codex App are you using?

Post-update reproduction:

  • ChatGPT / Codex Desktop: 26.825.31414
  • About-dialog release date: August 28, 2026
  • Remote task session metadata: codex-cli 0.150.1
  • Surface: Codex Desktop with a managed Remote SSH Linux project

Pre-update comparison from the same account/remote workflow:

  • Desktop: the pre-26.825 build (the exact About-dialog string was not retained in the remote rollout)
  • Remote task session metadata: codex-cli 0.149.1
  • Result: the same failure

For an exact earlier Desktop/CLI build pair with the same symptom, see #40852: Desktop 26.820.60940 / bundled CLI 0.150.0-alpha.8.

What platform is your computer?

  • Desktop controller: macOS
  • Execution host: remote Linux over Codex Remote SSH
  • Authenticated ChatGPT Codex session

What issue are you seeing?

Updating both the Desktop app and the remote Codex runtime did not restore the effectful first-party task-management tools.

A brand-new Remote SSH task created after installing Desktop 26.825.31414 records cli_version: 0.150.1. Its callable Codex App catalog still contains the read/helper side:

  • list_threads
  • list_archived_threads
  • read_thread
  • wait_threads
  • title, pin, archive, and share helpers

But the effectful side is still omitted:

  • create_thread
  • send_message_to_thread
  • fork_thread
  • handoff_thread
  • automation_update

The result is the same fail previously reported in #40865 and #40852: read/list/wait work, while user-authorized creation and inter-task coordination are unavailable.

This is a release-verification follow-up, not a new root-cause claim. The purpose is to record that Desktop 26.825.31414 plus remote CLI/app-server 0.150.1 still reproduces the regression in a fresh post-update task.

Version matrix

Observation Desktop app Remote task CLI Task state Result
Local pre-update reproduction Pre-26.825 build; exact About string not retained 0.149.1 Existing Remote SSH workflow Fail
Local post-update reproduction 26.825.31414 0.150.1 Brand-new post-update Remote SSH task Fail
Earlier exact published reproduction (#40852) 26.820.60940 bundled 0.150.0-alpha.8 Fresh code-mode tasks Fail

The official changelog currently lists CLI 0.150.1 as a remote-compaction fix and does not document a repair for this Desktop task-tool projection issue.

What steps can reproduce the bug?

  1. Install ChatGPT / Codex Desktop 26.825.31414.
  2. Connect to a managed Remote SSH Linux project.
  3. Confirm the remote Codex runtime and new task session metadata report 0.150.1.
  4. Create a completely new Desktop task after the update.
  5. Inspect the callable Codex App task-tool inventory.
  6. Confirm that list_threads, read_thread, and wait_threads are present and callable.
  7. Attempt to locate create_thread, send_message_to_thread, fork_thread, or handoff_thread.
  8. Observe that those tools are absent, so a standard project-owned task cannot be created or messaged from the source task.

What is the expected behavior?

The Desktop task-tool migration/projection should expose a coherent task-management surface on Remote SSH hosts:

  • When read/list/wait tools are available, explicitly user-authorized create/send/fork/handoff tools should also be available through the supported Codex App MCP path.
  • A fresh post-update task should be able to create a normal user-owned task inside the selected Desktop project and send it a visible message.
  • Desktop instructions must agree with the callable tool catalog.
  • If policy intentionally removes a capability, the task should receive a structured diagnostic instead of silently missing only the effectful half of the tool family.

Impact

This prevents normal user-owned multi-task orchestration:

  • no project-owned worker/reviewer task creation;
  • no visible callback or follow-up message to an existing task;
  • no standard fork or handoff lifecycle;
  • internal subagents are not an equivalent replacement for separate user-owned Desktop tasks;
  • raw app-server fallback creation is not equivalent because it can produce a task with no Desktop project association.

Additional information

  • The model configuration is not the failure: gpt-5.6-luna with max reasoning was independently able to complete a direct app-server turn.
  • The failing boundary is the Desktop task-tool projection/project orchestration surface.
  • No raw task IDs, hostnames, repository contents, credentials, or full rollout logs are included here. Sanitized tool inventories and session metadata can be supplied privately if needed.

Related:

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    app-serverIssues involving app server protocol or interfaces
    tool-callsIssues related to tool calling
    on Aug 28, 2026
  2. shockbladenull commented on Aug 28, 2026

    @shockbladenull
    Author

    Rollback verification: core thread orchestration recovers on Desktop 26.818.61809

    I rolled back the macOS Desktop app from 26.825.31414 to 26.818.61809 (released Aug 24, 2026), fully restarted the app, and created completely new tasks in the same managed Remote SSH project.

    The remote runtime was not rolled back and still reports:

    • codex-cli 0.150.1
    • the same Remote SSH host/project workflow

    I repeated the fresh-task verification twice. In both new tasks, the callable Codex App catalog included:

    • codex_app__create_thread
    • codex_app__send_message_to_thread
    • codex_app__fork_thread
    • codex_app__handoff_thread

    The read/helper tools also remained available.

    The end-to-end create/send path succeeded in both runs:

    1. list_projects resolved the Remote SSH project.
    2. create_thread accepted an explicit project target plus gpt-5.6-luna / max.
    3. The created user-visible task completed and returned the expected unique create marker.
    4. send_message_to_thread continued that same task.
    5. The task returned the expected unique send marker.
    6. read_thread confirmed both completed turns.
    7. No extra approval prompt occurred.

    The disposable diagnostic tasks were then archived successfully.

    Desktop Remote CLI Task state Result
    26.825.31414 0.150.1 Brand-new Remote SSH task Fail: create/send/fork/handoff absent
    26.818.61809 0.150.1 Brand-new Remote SSH task, tested twice Pass: create/send E2E succeeded; fork/handoff present

    Two important residual observations:

    • A task that existed before the rollback still has the old partial tool catalog. The effectful tools were not retroactively injected into that existing task. A brand-new task was required after the rollback/restart.
    • automation_update is still absent on 26.818.61809, so this is specifically a recovery of the core user-owned task/thread orchestration surface, not every previously missing effectful tool.
    • The create request explicitly targeted the Desktop project, and the created task used the expected Remote SSH host/cwd, but subsequent list metadata still showed projectId: null. The create/send behavior itself worked.

    This keeps the remote CLI constant and changes only the Desktop build, which strongly points to a Desktop-side regression. Based on the available exact builds, the regression window is narrowed to after 26.818.61809 and present by 26.820.60940.

  3. antonincohen commented on Aug 31, 2026

    @antonincohen

    Fresh 0.151.0 app-server verification: replacing the stale remote runtime does not restore the tools

    I reproduced the same omission on August 31, 2026 in a managed Codex Desktop Remote SSH Linux project after fully replacing the previously running remote app-server.

    Sanitized verification:

    • Installed remote CLI: 0.151.0
    • Running app-server: 0.151.0
    • Running app-server proxy: 0.151.0
    • The prior 0.144.5 app-server processes were no longer present.
    • The new 0.151.0 app-server started at 09:43 UTC.
    • The affected Desktop task was created afterward, at 09:46 UTC.
    • Its rollout metadata records originator: Codex Desktop, source: vscode, and cli_version: 0.151.0.

    The fresh task still exposes the read/helper side, including list_threads, read_thread, and wait_threads, but omits:

    • create_thread
    • send_message_to_thread
    • fork_thread
    • handoff_thread

    This rules out the earlier hypothesis that an orphaned 0.144.5 server surviving a Desktop restart was the remaining cause. Killing that server, confirming that only the 0.151.0 server and proxy remained, and starting a new task did not change the projected task-tool catalog.

    A local rollout-history comparison also shows:

    • Desktop tasks in the same Remote SSH workflow exposed the effectful thread tools through August 25.
    • Tasks beginning August 30 omitted them.
    • The omission appeared with both the older and newer remote CLI/app-server versions.

    Combined with the rollback result already posted above, this further supports a Desktop-side tool-catalog/projection regression rather than an SSH connectivity problem or stale remote app-server binary.

    No hostnames, paths, account identifiers, repository contents, task IDs, or full rollout logs are included here. Sanitized process/version output and tool inventories can be provided privately if maintainers request them.

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 workingremotetool-callsIssues related to tool calling

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions