Repository navigation
[Desktop Remote SSH 26.825.31414] effectful task tools still missing with CLI 0.150.1 #41248
Description
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.825build (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_threadslist_archived_threadsread_threadwait_threads- title, pin, archive, and share helpers
But the effectful side is still omitted:
create_threadsend_message_to_threadfork_threadhandoff_threadautomation_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?
- Install ChatGPT / Codex Desktop
26.825.31414. - Connect to a managed Remote SSH Linux project.
- Confirm the remote Codex runtime and new task session metadata report
0.150.1. - Create a completely new Desktop task after the update.
- Inspect the callable Codex App task-tool inventory.
- Confirm that
list_threads,read_thread, andwait_threadsare present and callable. - Attempt to locate
create_thread,send_message_to_thread,fork_thread, orhandoff_thread. - 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-lunawithmaxreasoning 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:
- [Desktop Remote SSH] inter-task tools stopped before update; 0.148 lacks codex_app MCP replacement #40865 — Remote SSH migration to the Codex App MCP replacement is incomplete
- [macOS Desktop 26.820.60940] code-mode tasks omit send_message_to_thread while read tools remain #40852 — Desktop
26.820.60940omits effectful task tools while read tools remain
Activity
github-actions commentedon Aug 28, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
shockbladenull commentedon Aug 28, 2026
Rollback verification: core thread orchestration recovers on Desktop 26.818.61809
I rolled back the macOS Desktop app from
26.825.31414to26.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.1I repeated the fresh-task verification twice. In both new tasks, the callable Codex App catalog included:
codex_app__create_threadcodex_app__send_message_to_threadcodex_app__fork_threadcodex_app__handoff_threadThe read/helper tools also remained available.
The end-to-end create/send path succeeded in both runs:
list_projectsresolved the Remote SSH project.create_threadaccepted an explicit project target plusgpt-5.6-luna/max.send_message_to_threadcontinued that same task.read_threadconfirmed both completed turns.The disposable diagnostic tasks were then archived successfully.
26.825.314140.150.126.818.618090.150.1Two important residual observations:
automation_updateis still absent on26.818.61809, so this is specifically a recovery of the core user-owned task/thread orchestration surface, not every previously missing effectful tool.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.61809and present by26.820.60940.antonincohen commentedon Aug 31, 2026
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:
0.151.00.151.00.151.00.144.5app-server processes were no longer present.0.151.0app-server started at 09:43 UTC.originator: Codex Desktop,source: vscode, andcli_version: 0.151.0.The fresh task still exposes the read/helper side, including
list_threads,read_thread, andwait_threads, but omits:create_threadsend_message_to_threadfork_threadhandoff_threadThis rules out the earlier hypothesis that an orphaned
0.144.5server surviving a Desktop restart was the remaining cause. Killing that server, confirming that only the0.151.0server and proxy remained, and starting a new task did not change the projected task-tool catalog.A local rollout-history comparison also shows:
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.