Repository navigation
Codex Desktop automation_update schema disagrees with backend (cwds vs projectId) #32873
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Codex Desktop 26.707.62119 (build 5211).
Bundled/session CLI observed from the affected environment: codex-cli 0.142.5.
What subscription do you have?
API key.
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
A local Codex Desktop thread exposes codex_app.automation_update, but the tool's model-visible input schema and its Desktop/backend validator disagree.
The exposed schema accepts cwds for a cron automation and does not expose a projectId field. Updating an existing local automation with the documented fields fails with:
automation_update received invalid arguments: projectId: Invalid input: expected string, received undefined; arguments: Unrecognized key: "cwds".
Trying to supply the existing automation's project ID does not provide a workaround because the exposed tool schema rejects that field:
automation_update received invalid arguments: arguments: Unrecognized key: "projectId".
The same mismatch occurs for both immediate update and reviewable suggested_update calls. The automation definitions remain present and active on disk, but there is no supported callable payload that can update them.
What steps can reproduce the bug?
- Open a local project thread in Codex Desktop.
- Ensure an existing local cron automation is present.
- Inspect or load the exposed
codex_app.automation_updatetool schema. - Call
automation_updateinupdatemode with the existing automation ID, its full preserved fields, and:{ "executionEnvironment": "local", "cwds": ["/Users/me/Development"] } - Observe that the backend requires
projectIdand rejectscwds. - Retry with
projectIdcopied from the existing automation's stored project target. - Observe that the exposed tool validator rejects
projectIdas an unrecognized key. - Restart Codex Desktop, reopen the local task, and repeat. The mismatch persists.
- Repeat with
suggested_update; the same validation mismatch occurs.
No automation TOML files were edited during this reproduction.
What is the expected behavior?
The model-visible tool schema and the Desktop/backend validator should accept the same automation target fields.
For an existing automation, one of these should work:
- the tool accepts
cwdsand resolves the project target internally; - the tool exposes and accepts the required
projectId; or - the update operation resolves the existing project target from the automation ID without requiring it again.
Restarting Desktop should not leave the thread with an impossible tool contract where every valid-looking target payload is rejected.
Additional information
This appears distinct from:
- Desktop exposes automation_update without a handler, leaving automations unmanageable #32294, where
automation_updateis exposed but has no registered handler; - Codex Desktop inconsistently exposes automation_update across local threads #29128, where
automation_updateis inconsistently absent across local threads.
Here, the tool is exposed and reaches argument validation, but the model-visible schema and backend-required schema are mutually incompatible.
The issue prevents safe updates to existing automations. Directly editing automation TOML files would bypass Desktop validation and reload semantics, so it is not a suitable supported workaround.
Activity
wrn4pdzj4v-blip commentedon Aug 4, 2026
Reproduced a closely related current failure on Codex Desktop for macOS 26.721.81911 (build 5973).
The exposed
automation_updateschema now acceptsprojectId, but it exposes nocwd/cwds/replace-cwd field. Updating existing local cron automations against the only saved project succeeds and preserves all other fields, yet app-managed read-back still retains a stale second project path:Reproduction:
/Users/me/Project.automation_updateoperation with the existing automation ID, current full fields, and the canonical savedprojectId.Project-local and user Codex configuration contain only the canonical project; local-environment configuration also has no scheduled-task cwd replacement surface. Direct TOML editing was intentionally not used because it would bypass Desktop validation/reload semantics.
Expected: selecting/updating an automation against a saved project replaces the stored cwd set with that project, or the supported API exposes an explicit replacement field such as
cwds/replaceCwds.Impact: scheduled automations cannot be safely activated after a project-root migration because the retired root remains an execution target even though the app has only the canonical project saved.
omarpinarecords commentedon Nov 9, 2026
Related current-build evidence on macOS, ChatGPT desktop 26.1103.60933 (build 25894), November 9, 2026.
The current tool exposes
projectId, but no supported per-taskcwds/ordered-folder override. A genuinely local controller task (nativehostId: local) successfully calledautomation_update(mode: "view"); it returned a rendered card, not structured saved fields.Read-only inspection of the installed update path and saved definitions established a preservation problem before any write:
rootPaths.cwds.All six operations were stopped before pause/save. No live update or destructive reproduction was attempted; these are source-path/preimage comparison findings, not a claim that a mutation occurred. All 69 saved definitions still matched the baseline.
This differs from the older comment where stale paths remained after a successful save: on this build, automatic project-derived replacement prevents exact preservation. The shared gap is lack of an explicit supported folder-preservation/replacement contract.
Expected: preserve existing task folder bindings by default when unrelated fields change, and expose an explicit, reviewable ordered folder replacement when requested. At minimum, provide a preflight diff and reject unapproved membership/order changes rather than silently deriving a different list.
The related dot-host eligibility boundary is tracked at #54940. Its existing Dots feedback report ID is
6a26fa86c878415080045c6059043ba7; that receipt predates this newly isolated folder-preservation finding, so it is not claimed as a separate submission of this finding.No direct automation TOML/database writes, internal RPCs, host overrides, project-folder changes, permission expansion, or UI safety bypass were used. Private paths, project/task names and identifiers, documents and logs are omitted. Is there a supported current API/UI route that preserves exact per-task ordered folder lists while changing the project binding?