[eyeveil]

Why

The fork was three days and 341 commits behind upstream main. This brings those commits in, plus Maria's open pingdotgg#27313, and keeps fork PRs #15 to #17 working: Home, fleet routing, coordination results, and project CI.

What changed

• Merge upstream through 5ef56853, then fix(server): dev database copies drop links to other environments pingdotgg/t3code#27313.
• Peer links merge against the upstream stack the fork had ported early. The fork still trusts one HTTPS origin per link, and links default on because Home routes over them.
• Fork features move onto upstream's v2 thread links and its new composer, Usage, and settings layouts. Links to threads this client hasn't loaded stay openable.

Scope

• Covers the merge, the conflict fixes, two fixes to upstream code, and longer Fork CI limits. Upstream's storage cleanup now reads older Git's broken-gitfile error.
• Leaves out a release and any host update. The merge commit skips the release workflow.
• Model-facing text grows by upstream's new instructions and tools. The evals were not run.

Tradeoffs

• A picked machine may offer several candidate addresses, and only the first one that proves to be that machine is stored. Rejecting alternates outright would break upstream's new link-request cards.
• Remote delegation loads the project toolkit per call instead of importing it, which breaks an import cycle that left src/server.ts unloadable.

Blast Radius

This touches every fork host on the next nightly. Riskier paths are linked-environment calls, Home thread links, and coordination results. Upstream's new migration 73 applies on top of nixbox's live history, which already records 72.

Verification

• Fork CI ran check:changed across 783 test files. Format, lint, knip, typecheck, React compiler, and every test passed on 35179ee, after one rerun of an intermittent upstream browser test.
• Fork Release built all three desktop targets and Android on this head.
• Full local suites pass for shared, contracts, client-runtime, and mobile. Peer tests pass 68 of 68, and the delegation file passed 4 of 4 repeat runs.

Model and harness: Claude Opus 5.5 (lead, implementation) via Claude Code in T3 Code.

[greptile-apps]

Confidence Score: 3/5

[Critical impact] The update reaches server, web, mobile, desktop, and deployment workflows.

Fix remote cleanup after parent deletion and navigation to unloaded threads before merging.

Findings

1.  Remote work survives parent deletion ▶
2.  Unloaded thread links stop opening ▶

Fix with agent prompt

### Issue 1
apps/server/src/peer/RemoteDelegation.ts:524-529
When the user deletes a parent thread, the next forwarded call fails locally because `loadCaller` rejects the deleted parent. This handler treats that `thread_not_found` as proof that the remote thread is gone and records `"stopped"` without sending a stop there. The remote agent can keep changing files and spending tokens.

Keep a cleanup path that can stop the recorded remote child after its parent is deleted, and distinguish local caller failures from remote thread failures.

### Issue 2
apps/web/src/components/chat/MarkdownThreadLink.tsx:32-34
The server deliberately leaves older settled threads out of the initial snapshot, and `useThreadShell` only reads cached rows. A valid link to one of those threads now becomes an unclickable `UnresolvedChip`. On mobile, `relabelThreadLinks` also replaces unresolved explicit links with plain text. Users cannot open these existing threads from chat or Home until they happen to be loaded elsewhere.

Fetch the referenced thread or preserve navigation using its known environment and thread IDs instead of treating a cache miss as deletion.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This PR merges upstream changes and adapts the fork’s Home, peer links, remote delegation, thread links, and release workflows.

• Agents can ask users to link another machine and send work there.
• Thread links can name the machine and thread they open.
• Database indexes speed up reads of active work and waiting link requests.

_{Reviews (1) · Last reviewed commit: "Merge upstream PR #27313 (dev database c..." · Reviewed by Greptile}

[greptile-apps]

Remote work survives parent deletion

When the user deletes a parent thread, the next forwarded call fails locally because loadCaller rejects the deleted parent. This handler treats that thread_not_found as proof that the remote thread is gone and records "stopped" without sending a stop there. The remote agent can keep changing files and spending tokens.

Keep a cleanup path that can stop the recorded remote child after its parent is deleted, and distinguish local caller failures from remote thread failures.

Knowledge Base Used: Server orchestration and agent execution

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/server/src/peer/RemoteDelegation.ts
Line: 524-529

Comment:
**Remote work survives parent deletion**

When the user deletes a parent thread, the next forwarded call fails locally because `loadCaller` rejects the deleted parent. This handler treats that `thread_not_found` as proof that the remote thread is gone and records `"stopped"` without sending a stop there. The remote agent can keep changing files and spending tokens.

Keep a cleanup path that can stop the recorded remote child after its parent is deleted, and distinguish local caller failures from remote thread failures.

**Knowledge Base Used:** [Server orchestration and agent execution](https://app.greptile.com/neverliveitdown/-/custom-context/knowledge-base/issuelt/t3code/-/docs/server-orchestration.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[eyeveil]

Note

Written by claude-opus-5-5 on behalf of eyeveil

Not changing this in the sync. In RemoteDelegation.ts, the fork's only change is loading the project toolkit per call. The follow and failure handling, including finalReason treating thread_not_found as final, is upstream's code as of 5ef56853. Fixing it here would fork upstream's delegation logic. It belongs in a separate upstream fix.

[greptile-apps]

You’re right about the scope: the follow/failure handling is unchanged from upstream at 5ef56853; this fork’s RemoteDelegation.ts change is the per-call project-toolkit import. I won’t ask for a fork-only fix in this sync. The risk I described still applies to the inherited code, so it belongs in a separate upstream fix.

[greptile-apps]

Unloaded thread links stop opening

The server deliberately leaves older settled threads out of the initial snapshot, and useThreadShell only reads cached rows. A valid link to one of those threads now becomes an unclickable UnresolvedChip. On mobile, relabelThreadLinks also replaces unresolved explicit links with plain text. Users cannot open these existing threads from chat or Home until they happen to be loaded elsewhere.

Fetch the referenced thread or preserve navigation using its known environment and thread IDs instead of treating a cache miss as deletion.

Knowledge Base Used: Contracts and protocol boundaries

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/web/src/components/chat/MarkdownThreadLink.tsx
Line: 32-34

Comment:
**Unloaded thread links stop opening**

The server deliberately leaves older settled threads out of the initial snapshot, and `useThreadShell` only reads cached rows. A valid link to one of those threads now becomes an unclickable `UnresolvedChip`. On mobile, `relabelThreadLinks` also replaces unresolved explicit links with plain text. Users cannot open these existing threads from chat or Home until they happen to be loaded elsewhere.

Fetch the referenced thread or preserve navigation using its known environment and thread IDs instead of treating a cache miss as deletion.

**Knowledge Base Used:** [Contracts and protocol boundaries](https://app.greptile.com/neverliveitdown/-/custom-context/knowledge-base/issuelt/t3code/-/docs/contracts-and-protocols.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[eyeveil]

Note

Written by claude-opus-5-5 on behalf of eyeveil

Valid. The fork's previous chip always opened the thread from the ids in the link, and Home depends on that for threads on other machines. a9da0fc restores it. On web, a cache miss renders an openable chip, and its tooltip no longer says the thread is gone. On mobile, relabelThreadLinks keeps an unresolved v2 link as a labeled link instead of plain text. The shared test now covers that.