[macOS][Project association] Assistant reports missing Project association while saved native assignments exist #52632

Summary

Tasks repeatedly produce assistant messages saying that they have no Project association. In an October 9, 2026 observation, an assistant reported that a task was active in the intended Local working folder while its native Project association remained unconfirmed, citing projectId: null.

A subsequent read-only Local inspection found non-null saved native Local Project assignments for both the originally reported task and a diagnostic task created with explicit selection of an existing Project. Neither was explicitly marked projectless in the inspected saved app state.

The issue is the discrepancy between the association warnings and the saved assignments. The earlier null readback was not reproduced, and canonical durable-host membership and current sidebar presentation remain independently unverified. This report does not claim that saved membership was actually lost.

Environment

• macOS 27.0.1
• Desktop app 26.1007.21159, build 20052
• Bundled CLI protocol 0.162.0
• Observed October 9, 2026
• Local tasks with saved native Project assignments

These are the diagnostic environment values for this follow-up, not measurements of every earlier occurrence.

Observed sequence and evidence

1. The owner encountered repeated assistant messages reporting absent Project association.
2. One current conversation reported correct Local-folder execution but unconfirmed native association, citing projectId: null. This is verified conversation evidence of the assistant's report, not independently captured proof of that earlier native response.
3. A Local diagnostic task was created with explicit Project selection.
4. Read-only saved app-state inspection found non-null native Local Project assignments for both tasks and no explicit projectless marking.
5. Canonical durable-host membership and current UI/sidebar grouping could not be independently verified. No controlled reproduction of the original null response was obtained.

The inspected protocol supports Thread.projectId and explicit Project selection for durable-task creation. This establishes available controls, not which creation inputs were used for the earlier task or whether all membership interfaces agree.

Expected behavior

Keep these four facts distinct and consistently observable:

1. Actual working directory and execution computer.
2. Saved native Project membership.
3. Membership returned by task-list/read interfaces.
4. Visible sidebar grouping.

Assistants should label unresolved association as unverified. A matching working directory alone does not establish membership, and a null field alone does not establish that a saved assignment is absent.

Please investigate incomplete readback, host-specific membership resolution, synchronization and assistant interpretation separately. Any required recovery should preserve existing task IDs and history.

Related reports and scope

• [Desktop] Assistant-created tasks do not preserve requested Local Project destination and reasoning effort #49586 is the same owner's broader earlier report about requested Local Project placement and reasoning effort. This issue isolates the association-warning versus saved-assignment discrepancy; it adds no reasoning-effort regression claim.
• macOS 26.930: chats disappear inside project groups while saved assignments remain; API returns null membership #51477 and [macOS] Tasks created through app-server are searchable but missing from their assigned projects #48728 document related null-membership readbacks despite saved assignments. A shared cause has not been established.

The owner explicitly requested this separate issue. In-product feedback has not been submitted for this follow-up. Private Project names, paths, task/Project identifiers, conversation contents, legal information, screenshots and raw logs are omitted.