Keep a New chat from being undone by the check it raced

[kevin9327]

What this changes

A race in useBotThread (from #81). The hook verifies a remembered thread on mount — checkKnown, a network round-trip — before handing the id out. startNew (the New chat button) runs from an event handler and its mint is not held behind that check: checkKnown is a read, not a mint, so the mintingRef guard that serialises the two mints is clear while it runs.

So the two race:

1. Chat mounts with a remembered thread; checkKnown(existing) is in flight.
2. The person presses New chat; startNew mints a fresh thread.
3. startNew's mint resolves first → setThreadId(minted).
4. checkKnown resolves (known: true) → its handler runs setThreadId(existing).

The new chat is silently replaced by the old one — the person asked for a fresh conversation, watched it appear, and landed back in the previous one, with nothing on screen to explain it. Exactly the "pressing New chat should never leave you worse off" the hook already reasons about, in the one window it did not cover: the current flag the resolution reads only catches the agent changing or the component unmounting.

The fix mirrors the guards already there. startNew sets a startedNewRef; the mount-time resolution reads it, so a check about the thread the person just left cannot overwrite the one they just asked for. It resets at the top of the effect, so a new agent resolves from scratch.

Where it runs

• New state that outlives a request? None. One more useRef guard in the same hook, alongside the existing current and mountedRef. Nothing crosses to another process.
• What happens on the second replica? N/A — this is per-browser component state; the turn is driven from the browser and this id lives and dies with the mount.
• Anything serialised / fanned out / new listener? No. The only persistence (localStorage) is unchanged; the fix stops a stale write to React state, not to storage.

Boundary and audit

• No acting call, gateway, policy or audit path is touched. This is client-side thread-id resolution for the direct Bot chat.

Proof

• bun run typecheck (app) — clean.
• bun test app/tests app/src — 121 pass, unchanged. The hook's async coordination is not unit-tested here (the existing current/mountedRef guards are not either); the pure decision it wraps, threadToUse, is, and stays green. The fix is the same guard shape as those two, verified by the interleaving above.
• biome check — clean.

One useRef and one condition, matching the guards beside it; no storage, network, or decision logic changed.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[davidmckayv]

The race is real and this closes it. Driven in the browser rather than argued from the code, because the interleaving is a timing bug and the app has no React test harness.

Setup: /api/threads/mint stubbed to 500, /api/threads/<id> delayed 6s, a remembered thread in localStorage, then a soft remount so the mount-time check is genuinely in flight when New chat is pressed.

• With the latch at the press: chatPresent: false. The mint fails, the check finds itself disarmed, nothing replaces the thread, and bot.tsx renders the chat only when there is one. Empty pane, no message, no way back but a reload.
• With the latch moved after the if (!minted) return guard: chatPresent: true. The remembered conversation is restored.

Same script, same stubs, only the line moved. Pushed as 0b3614f.

It is not a weaker guard: the assignment and the check both run to completion on one thread, so a check resolving after it sees it, and one resolving before it has restored a thread this is about to replace, which is what was asked for.

typecheck, lint, format:check and bun test app (121 pass) are clean.