Codex Desktop rejects project-scoped automation creation for listed WSL projects but accepts projectless target

What version of the Codex App are you using?

ChatGPT/Codex Desktop 26.707.31428

Bundled runtime recorded in local rollout metadata: codex-cli 0.144.0-alpha.4

Platform

Windows host with local projects exposed to Codex through WSL-style paths.

What issue are you seeing?

The app's project discovery returns valid local projects whose projectId is a /mnt/c/... path. Creating a local cron automation against any such returned project ID fails immediately with only:

Failed to create automation.

The otherwise equivalent call succeeds when projectId is changed to null, creating a projectless automation.

This prevents using the intended project-scoped local environment even though the app itself listed and selected the project.

Steps to reproduce

1. On Windows, open a repository through the local WSL integration.
2. Call the app's project listing capability.
3. Confirm it returns a local project similar to:

{
  "projectId": "/mnt/c/Users/<user>/projects/<repo>",
  "projectKind": "local",
  "path": "/mnt/c/Users/<user>/projects/<repo>",
  "hostId": "local"
}

1. Attempt to create a paused minimal automation using that exact returned ID:

{
  "mode": "create",
  "kind": "cron",
  "name": "Temporary WSL project automation probe",
  "prompt": "Return exactly OK. Do not use tools or modify files.",
  "rrule": "FREQ=WEEKLY;BYDAY=MO;BYHOUR=9;BYMINUTE=0",
  "status": "PAUSED",
  "executionEnvironment": "local",
  "destination": "local",
  "projectId": "/mnt/c/Users/<user>/projects/<repo>",
  "model": "gpt-5.4-mini",
  "reasoningEffort": "low"
}

1. Observe Failed to create automation.
2. Repeat against a second project returned by the same listing call. The failure reproduces.
3. Change only projectId to null. Creation succeeds and writes an active/paused projectless automation.

Isolation performed

• Reproduced against two separate listed local projects.
• One repository had unrelated uncommitted/conflicted state.
• The second repository was a clean Git working tree, excluding dirty-repository state as the cause.
• Used executionEnvironment = "local", not worktree mode, excluding managed-worktree setup.
• The same model, effort, prompt, schedule shape, destination, and status are accepted for a projectless target.
• No automation definition is created for the failed project-scoped calls.
• A projectless definition is created immediately for the successful control.

Expected behavior

A projectId returned by the app's own project-list API should be accepted by automation creation, and the scheduled task should be bound to that local project.

If the project cannot be used, creation should return an actionable validation error identifying the rejected field and expected path/host representation.

Actual behavior

Project-scoped creation fails with a generic message. Projectless creation succeeds, forcing the prompt to carry an absolute local path as a workaround and losing the intended project binding.

Likely failure boundary

There may be an identity/path-normalization mismatch between:

• the WSL-form project ID returned by project discovery;
• the Windows desktop automation manager's accepted project identifier; and
• the local execution target resolver.

An opaque stable project ID, or normalization through the same path/host layer on both list and create, would avoid the caller receiving an identifier that the next API rejects.

Acceptance criteria

• A listed local WSL project can be selected for a local cron automation.
• The automation persists the correct project target.
• A clean and a dirty Git working tree are both accepted for local/read-only automation creation.
• Invalid targets return a specific validation error rather than Failed to create automation.
• Tests cover round-tripping list_projects.projectId into automation creation on Windows + WSL.

Privacy note

The username, repository names, absolute paths, automation prompt, thread/session IDs, and account details were replaced or omitted. The sanitized path shape and API payload retain all information needed to reproduce the cross-OS identifier problem.