SSH remote helper remains stale after app updates and causes opaque reserved-tool 400
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.4k
- PR merge metrics
- PR metrics pending
Description
SSH remote helper remains stale after app updates and causes opaque reserved-tool 400
What issue are you seeing?
An SSH-connected Codex host continued running an older standalone remote helper even after both desktop apps were updated. The desktop detected the remote helper version and treated the host as connected, but every new or resumed remote task failed before model output with:
Invalid Value: 'tools'. Function 'collaboration.spawn_agent' is reserved for use by this model and must match the configured schema.
The failure appeared to be task corruption or a model/tool problem. In fact, the controller and SSH helper were on incompatible Codex versions.
Observed versions:
- Controller desktop-bundled Codex:
0.151.0-alpha.7.2 - Remote macOS desktop-bundled Codex:
0.151.0-alpha.7.2 - SSH-installed standalone helper:
0.150.0
Updating the ChatGPT desktop app on the remote Mac did not update the separate helper under $CODEX_HOME/packages/standalone/current. The controller logged the remote helper as 0.150.0 but still allowed the connection and task execution to proceed.
Steps to reproduce
- Connect an updated ChatGPT desktop app to a macOS host over SSH.
- Have the remote Mac desktop app updated to a newer Codex build while the SSH-installed standalone helper remains on the previous build.
- Reconnect to the SSH host. The host appears connected even though the controller reports the older remote helper version internally.
- Send an ordinary follow-up in an existing remote task, or start a new task on the same SSH host.
- Observe the request fail before inference with the reserved
collaboration.spawn_agentschema error. - Install a standalone helper matching the controller's Codex version and restart the remote app server.
- Observe that the original long-running task resumes successfully with its existing history and worktree.
Expected behavior
The SSH bootstrap should compare the controller and remote app-server/tool-schema versions before accepting the connection. If an update is required, it should either update the versioned standalone helper atomically or stop with a clear, actionable message such as:
The SSH host is running Codex 0.150.0, which is incompatible with desktop Codex 0.151.0-alpha.7.2. Restart the SSH connection to update the remote helper.
Updating the desktop app on the remote Mac should either update the SSH helper too, or the UI should clearly explain that the SSH helper is a separate installation.
An internal reserved-function schema error should not be the user-facing symptom of a detected remote version mismatch.
Actual behavior
- The remote Mac app was current, but its separate SSH helper remained stale.
- The controller detected the old helper version and still reported the host as connected.
- New and existing tasks on that host failed with a non-actionable internal tool-schema error.
- The error did not mention version mismatch, remote helper update, or the documented restart-to-update path.
- Manually aligning the helper version and restarting the remote app server restored the original task without recreating it.
Workaround
Install the same Codex build as the controller into a new versioned directory under $CODEX_HOME/packages/standalone/releases, repoint $CODEX_HOME/packages/standalone/current, and restart the SSH app-server process.
Related issue
The exact reserved-tool error is already tracked in #31864. This report concerns the SSH-specific update/compatibility path that can leave an older helper active and surface that error after an app update.
Privacy note
This report intentionally excludes hostnames, IP addresses, usernames, repository and project names, filesystem paths outside generic product locations, task/session IDs, filenames, diffs, prompts, credentials, and full logs. A minimal redacted version tuple can be provided if needed; raw logs and session transcripts should not be required to reproduce the compatibility check.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the SSH bootstrap and the standalone helper locations under $CODEX_HOME/packages/standalone/current and releases; reproduce the mismatch between the controller and remote helper versions. Done means the compatibility check prevents an incompatible connection or provides a clear update message, rather than allowing the opaque reserved-tool error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100