Mobile drafts lose the initially selected project #30095

Before submitting

• I searched existing issues and did not find a duplicate of this initial draft-binding race.
• I included enough detail to reproduce or investigate the problem.

Area

apps/mobile

Steps to reproduce

1. In the native mobile app, start a new thread and choose an existing project, such as t3code, rather than No project.
2. Enter Hello! without sending it.
3. Go Back to the main screen and inspect the saved draft under Unsent.
4. Open that saved draft.

Expected behavior

The saved draft and reopened composer retain the chosen project and text.

Actual behavior

The composer initially displays t3code, but after the first Back the draft appears under No project. Reopening restores the text with No project selected. Selecting t3code again and going Back makes the project stick.

Impact

Minor bug or occasional failure. The user must reselect the project when returning to the draft; sending without noticing can start work in the wrong project.

Version or commit

The reporter described the latest native iOS app on 2026-11-03; its exact version/build is unknown. Connected Linux server: 0.1.7-nightly.20261103.4119. Source-level reproduction: cefb544af3c98224874419198c0359b652ca3c94.

Environment

Native T3 Code iOS app connected to a Linux arm64 environment. The draft-state behavior is client-side and independent of the selected coding provider.

Diagnosis

NewTaskDraftScreen applies the initial project in a child mount effect. setProject synchronously creates and binds the draft for that project. The parent's NewTaskFlowProvider creation effect then runs with the previous render's activeDraftKey === null and fallback project. It creates a second draft and overwrites the flow's draft binding while leaving its displayed project selection intact.

Reading the live flow's draft binding before creating the fallback draft prevents that overwrite. This explains why choosing the project again works: subsequent selections retarget the existing draft.

Evidence

The reporter supplied an iOS recording showing Hello! first saved under No project, then under t3code after selecting the project again. The recording is not attached to this public report.

A focused test mounting the actual provider with a child effect selecting another project reproduces the mismatch on the unmodified source:

Displayed project: two/b
Expected saved draft: { environmentId: "two", projectId: "b" }
Actual saved draft:   { environmentId: "one", projectId: "a" }

After guarding creation with the live flow binding, the same test passes and reopening the draft retains both the selected project and Hello!. Provider and flow-state tests: 13/13 pass.

This is a React source-level reproduction, not an independent iOS run. Agent device access is disabled in the verification environment, so native before/after captures could not be collected.

Related issues

• [Bug]: Mobile new-task draft is saved under Unsent but not resumed when navigating away #15974 concerns New thread not resuming an unsent draft; this report concerns a draft that is reopened but already has the wrong project stamp.
• [Bug]: Mobile New thread ignores the active project filter and reuses the previous project #29034 concerns the active project filter versus remembered picker selection; this report concerns the displayed project and persisted draft disagreeing after selection.

Workaround

Reopen the draft, select the intended project again, then go Back. No changes were made to the installed app or live database during investigation.

Prepared with GPT-6.1 Sol in Codex through T3 Code.