›_ Codex Issues
Codex Issues / #37021

[Windows][Desktop] task list returns projectId=null for a valid directly bound local-project task

Open 💬 3 comments Opened Aug 5, 2026 by looneydweeb-cpu

What version of the Codex App are you using?

  • Codex Desktop: 26.730.7989.0
  • Bundled CLI/session metadata: 0.147.0-alpha.1.2

Platform

  • Windows 11 Pro, x64
  • OS build 26200
  • Local saved project with one primary folder and two additional attached roots
  • Project uses a native UUID project ID

What issue are you seeing?

For some existing local-project tasks, Codex Desktop's task-list metadata reports:

{
  "projectId": null,
  "cwd": "<the project's exact primary folder>"
}

However, the same task has a valid direct entry in thread-project-assignments:

{
  "projectKind": "local",
  "projectId": "<the saved local project's UUID>",
  "cwd": "<the project's exact primary folder>",
  "pendingCoreUpdate": false
}

The task is not present in projectless-thread-ids. Runtime request metadata also reports workspace_kind: "project", and the configured primary and additional workspace roots are available.

This creates a false-negative binding check: callers relying on the task-list projectId conclude that the task is projectless even though its direct assignment and runtime workspace are correct.

Controlled comparison

A minimal diagnostic task was created through the app's project-aware task creation API using the exact project ID and local environment.

The new task:

  • received the same direct project assignment;
  • used the same primary cwd;
  • was not marked projectless;
  • and was correctly returned by the task list with the non-null project ID.

At the same time, the older affected task still returned projectId: null.

This rules out a general failure of native UUID local projects and suggests stale or path-dependent per-task metadata projection/sidebar aggregation.

Steps to reproduce

The original trigger is not yet deterministic, but the observed state can be checked as follows:

  1. Create or select a native local saved project in Codex Desktop.
  2. Configure a primary folder and additional attached roots.
  3. Create a task from the project UI.
  4. Compare the task's project association across:
  • the saved-project registry;
  • thread-project-assignments;
  • projectless-thread-ids;
  • runtime workspace kind and cwd;
  • the task-list projectId.
  1. Observe that an affected task can have a valid direct assignment and project runtime while the task list alone reports projectId: null.
  2. Create a control task via project-aware task creation using the same project ID.
  3. Observe that the control can report the project ID correctly while the older task remains null.

Expected behavior

All supported task/project metadata surfaces should agree. If a task has a valid direct local-project assignment and is not marked projectless, task listing should return that project ID.

If the task-list field is only advisory or derived, the API should expose an authoritative binding status so callers do not mistake a projection defect for a real projectless task.

Actual behavior

The task-list projection can return projectId: null for a genuinely bound task. No project, sandbox, filesystem, or Windows access error is emitted.

Safety and privacy

  • Project, task, account, and absolute path identifiers are omitted.
  • No internal state was edited.
  • Filesystem access was separately verified with a uniquely named empty temporary file that was created, confirmed as zero bytes, deleted, and confirmed absent.
  • A global diagnostic guardrail now treats task-list projectId as corroborating rather than sole authority.

Acceptance criteria

  • Task-list projectId round-trips from the authoritative direct assignment for existing local tasks.
  • Multi-root local projects are covered.
  • Tasks created through both the project UI and project-aware task creation API are covered.
  • A repair/reconciliation pass refreshes stale per-task project projections without requiring users to edit internal state.
  • Tests cover disagreement among task list, direct assignment, projectless status, and runtime workspace context.

View original on GitHub ↗

3 Comments

looneydweeb-cpu · 23 days ago

Post-restart result:

After fully quitting and reopening Codex Desktop, the stale task-list projection reconciled without editing any internal state.

At 2026-08-04 21:12 PDT:

  • the previously affected current task now returned the correct non-null local project UUID from task listing;
  • a second previously affected task in the same multi-root project also returned the correct project UUID;
  • both values matched their existing direct thread-project-assignments;
  • pendingCoreUpdate remained false;
  • the current task remained absent from projectless-thread-ids;
  • runtime metadata still reported workspace_kind: "project";
  • the primary folder and both additional attached roots remained accessible;
  • a uniquely named zero-byte file was created directly in the primary folder, verified, deleted, and verified absent.

Installed build remained 26.730.7989.0.

This establishes a working recovery procedure for this occurrence: full quit and restart, not hand-editing project state. The underlying defect still matters because the task-list projection can temporarily disagree with an already-correct authoritative assignment and cause false binding failures before reconciliation.

aidawilliam41-ops · 13 days ago

Fresh project-aware create_thread occurrence

This is still reproducible on Windows with Codex Desktop 26.810.6296.0.

A native project-aware creation was invoked with:

  • target.type=project;
  • a valid saved-project UUID returned by the current project inventory;
  • environment=worktree;
  • startingState=working-tree.

The call first returned a queued client-thread identity, then materialized one task and completed its initial turn. The resulting task had:

  • the expected managed worktree for the selected saved project;
  • the expected project-local configuration;
  • a healthy idle task state after the first turn.

However, repeated native task-list readback returned:

{
  "projectId": null,
  "cwd": "<managed worktree for the selected project>"
}

At the same time, the saved-project inventory still returned the exact project UUID supplied to creation.

This extends the original report: the disagreement is not limited to an older task with a stale projection. A newly created task can lose the requested project association in the task-list result immediately after project-aware creation.

Expected behavior: a successful project-targeted creation should persist and read back the selected project ID atomically. If creation is queued, the ready/materialized result should also expose the effective projectId, cwd, and reconciliation status.

No project IDs, task IDs, usernames, absolute paths, internal state files, or user content are included. No state was edited for this reproduction.

M-T-D-N · 2 days ago

Fresh occurrence and later reconciliation (Windows)

Reproduced on 2026-08-24 in Codex Desktop on Windows 11 x64 (OS build 26200; bundled session metadata 0.149.0-alpha.4.1).

During the occurrence:

  • task listing returned projectId: null for the active task while its cwd matched the saved local project's root;
  • thread-project-assignments contained the correct local project ID;
  • the task was absent from projectless-thread-ids;
  • sidebar project order contained the task under the same project;
  • a comparison task in the same root returned the correct non-null project ID;
  • repeated task-list reads during the active session continued to return null.

On 2026-08-26, the same task now returns the correct non-null project ID. The direct assignment, projectless status, and sidebar placement are unchanged. No internal state was edited. A full app restart occurred between checks, so this independently confirms the transient projection/reconciliation behavior and restart recovery already described above.

All task/project identifiers and absolute paths are omitted.

AI disclosure

At the user's direction, this feature request was investigated, drafted, and posted by an AI agent (OpenAI Codex) on the user's behalf. The user authorized the submission and completed GitHub authentication.