feat(claude): reauthenticate failed V2 threads by flamboh · Pull Request #9179 · pingdotgg/t3code

flamboh · 2026-09-02T06:32:02Z

Note

🤖 GPT-6 on behalf of Oliver

ELI5

Sign back into Claude from the failed thread, including when the environment runs on another machine.

Problem

Expired Claude subscription credentials strand a failed task. This draft targets Julius's V2 branch, t3code/codex-turn-mapping, and depends on #2829.

Fix

Run Claude login on the selected environment and provider instance, show its browser link, and accept a pasted code in web, desktop, and mobile. V2 captures the failed run before login and retries its persisted prompt and attachments only while it remains current. Login and retry have separate outcomes; cancellation and changed threads or provider settings cannot silently resume stale work.

UI Changes

Before

The thread shows an authentication error without an in-app recovery action.

Before: authentication failure with no recovery action

After

The error offers Reauthenticate. The compact dialog keeps the sign-in URL on one scrollable line and closes when the task resumes. Retry failures remain visible.

After: reauthenticate and resume the failed V2 task

Recorded on b02e0821c with Playwright against the real app, SDK adapter, and V2 server. Claude CLI responses are simulated; no real credentials were changed.

Validation

Focused authentication, provider maintenance, V2 recovery, and client tests; scoped server, contracts, client-runtime, web, and mobile typechecks; targeted lint and formatting.

Browser verification covers the recovery button, cancellation and reopening, code submission, successful retry of the original prompt, and removal of the recovery action after completion. The banner fix passed 26 focused tests and the web typecheck. The dialog changes passed 20 focused tests, web/mobile typechecks, targeted lint, and desktop/phone-width browser checks. Real Anthropic account sign-in remains unverified.

Changes by GPT-6 through Codex, with GPT-5.6 Luna agents assisting implementation and review.

macroscopeapp · 2026-09-02T06:39:43Z

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a cross-layer Claude reauthentication workflow that launches an interactive login command, handles provider credentials and environment selection, persists new error state, and exposes a new authorized RPC. The authentication-sensitive scope and unresolved risks around command output, instance targeting, and locality require human review.

Not approved because:

3 blocking correctness issues found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

…ojects (pingdotgg#3640) Restore versioned shell-cache hydration, reconcile repository enrichment across multiple environments, and decode non-null settled shell timestamps correctly.

) Normalize subagent result disclosure across timeline rendering and collapsed/expanded states. Co-authored-by: codex <codex@users.noreply.github.com>

…dotgg#3754) Expose MCP tools for worktree handoff and status inspection, with focused server and contract coverage. Co-authored-by: codex <codex@users.noreply.github.com>

Co-authored-by: codex <codex@users.noreply.github.com>

Reset snooze metadata when creating forks and provider subagent children, with focused regressions for both inheritance paths. Co-authored-by: codex <codex@users.noreply.github.com>

Co-authored-by: codex <codex@users.noreply.github.com>

Wake replay stream waiters when outbound validation fails and ensure interrupted recordings close when no tool use arrives. Co-authored-by: codex <codex@users.noreply.github.com>

Remove the unreferenced V1 activity payload projection that arrived from main and assert only the public serialized SchemaError shape under Effect beta.102. Co-authored-by: codex <codex@users.noreply.github.com>

- Defer continuation offers for background completions that land while a root turn is active and un-finalized; finalize offers exactly one wake only when unhandled completed work remains - Stop late monitor-event mutations from erasing in-turn handled marks, so injected-turn ack chatter is never retained as wake evidence - Clear stale wake buffer frames at non-continuation user-turn start - Make the late-mutation suppress logic's running/terminal branches mutually exclusive

This PR introduces the only wakeBuffer clear at the ACP startTurn site, and it also clears midTurnUnreportedCompletedTaskIds there, both on the reasoning that a user turn owns the conversation. An orchestrator-injected wake is not a user turn. pingdotgg#4499 fix/delegated-task-parent-wake dispatches app-owned delegated-child wakes as creationSource "server", which is non-continuation, so once both land such a wake would discard this session's pending native wake frames and its kept mid-turn completion marks, losing agent output and a continuation offer that nothing else can recover. acpIsAppOwnedWakeTurn exempts orchestrator-injected wakes from both clears, matching what ClaudeAdapterV2 already does with its own buffer. Inert without pingdotgg#4499, since nothing else dispatches creationSource "server". Kept as its own commit because the concern originates in a different PR.

An app-owned delegated child wrote its result into the parent projection but never started a parent run, so an async delegation's result sat unread until the user's next message. Offer a provider continuation request when a delegated child terminalizes, with a per-task completionWake policy separating async delegations from blocking waits. The wake must also reach the model. ProviderContinuationRequests is a provider-native mechanism whose dispatch only triggers ingestion of output the adapter already buffered, and both ClaudeAdapterV2 and AcpAdapterV2 discard the message text when it is marked creationSource provider. An app-owned child buffers nothing, so a wake marked that way settled instantly having prompted nothing. App-owned wakes now dispatch as message_text via a shared delegatedTaskWakeRequest helper used by both producers. Co-authored-by: codex <codex@users.noreply.github.com>

A Claude V2 turn whose terminal SDK result carried origin.kind "task-notification" had that result discarded, so the run stayed running forever and every run queued behind it stalled. The drop is now limited to results reporting zero model turns, which is what the stale debris the guard was written for actually looks like. ClaudeAdapterV2 dropped any task-notification-origin result unless the turn was an agent/provider continuation. An app-owned delegated-task wake run is agent/server, so its terminal results were discarded and finalizeActiveTurn never ran. Any turn whose final result carries that origin hangs, not just wakes. Observed in production against a real session: three terminal success results with num_turns 154, 60 and 7 were all dropped, the session went silent for 8h27m, and five queued runs behind it never dispatched. The guard could not simply be deleted. After interrupt recovery a stale stopped task_notification and its origin result interleave ahead of the real root assistant stream and must not terminalize the turn or leak their text. Zero-turn results are still dropped, so that path is unchanged: this drops strictly fewer results than before, so no previously working path can regress. num_turns separates the two cases cleanly. The existing stale fixture sets numTurns 0 explicitly, makeResultFrame defaults to 1, and the production results all carried positive turns. The predicate is num_turns === 0 rather than < 1 or a truthiness check on purpose: num_turns is required on both result variants in 0.3.205, but if an older emitter ever omitted it, undefined === 0 is false, so the result is accepted rather than dropped. That fails toward terminalizing rather than toward the hang class this fixes. Both drops and accepts are logged with num_turns, stop_reason, terminal_reason, result uuid, session id and message provenance. The drop is debug level because interrupt recovery produces it routinely; the accept is info, because a positive-turn task-notification result settling a non-continuation turn is both the hang fix working and the exact shape a stale positive-turn result would take. Co-authored-by: codex <codex@users.noreply.github.com>

Co-authored-by: codex <codex@users.noreply.github.com>

macroscopeapp · 2026-09-08T01:58:04Z

+          activeAttemptIdRef.current = null;
+          activeRequestRef.current = null;
+          updateState(nextState);
+        } else {


🟠 High threads/ClaudeReauthenticationSheet.tsx:451

After a nonterminal awaiting_code response, submitCode leaves the sheet in phase: "submitting", so the input and submit control remain disabled and the user cannot correct or resubmit the code. Restore phase: "waiting" when the transition returns submitting.

- updateState(nextState); + updateState( + nextState.phase === "submitting" ? { ...nextState, phase: "waiting" } : nextState, + );

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/mobile/src/features/threads/ClaudeReauthenticationSheet.tsx around line 451: After a nonterminal `awaiting_code` response, `submitCode` leaves the sheet in `phase: "submitting"`, so the input and submit control remain disabled and the user cannot correct or resubmit the code. Restore `phase: "waiting"` when the transition returns `submitting`.

github-actions Bot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:L 100-499 changed lines (additions + deletions). labels Sep 2, 2026