[Bug]: CodeView duplicate-id crash on same-path type-change diffs still reproduces on Alpha 0.0.42 via remote T3 Connect session (post-#11074 fix)

[kpatel0170]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. In a Git repo, commit a regular tracked file, e.g. agents/foo.md, alongside another tracked file it can point to, e.g. agents/bar.md.
2. Replace agents/foo.md with a relative symlink to agents/bar.md and commit:

   rm agents/foo.md
   ln -s bar.md agents/foo.md
   git add agents/foo.md
   git commit -m "swap to symlink"

   This is a same-path Git type change (100644 -> 120000), which git diff --no-renames represents as two blocks for the same path (delete regular file, add symlink).
3. Connect to the environment through a remote/hosted T3 Connect session (not the local desktop app) and open the working-tree or commit diff for that path in CodeView.

Expected behavior

Per #11074 (closed as Completed 2026-09-18), CodeView should assign distinct ids to same-path type-change halves and render one type-change item, or at minimum not crash the thread.

Actual behavior

The renderer still throws and the thread shows "Something went wrong":

Error: CodeView.addItem: duplicate id "agents/foo.mdagents/foo.md"
    at e.appendItemsInternal (t3code://app/assets/diffFileContents-CFYwckRB.js:1:18149)
    at e.setItems (t3code://app/assets/diffFileContents-CFYwckRB.js:1:17760)

Note the asset hash diffFileContents-CFYwckRB.js differs from the one in #11074's report (diffFileContents-DyQONavv.js), and from #12244 (a different nightly build) — so this isn't a stale-cache repro of the old bug, it's a currently-shipping build.

Impact

Major degradation or frequent failure

Version or commit

T3 Code (Alpha) 0.0.42

Environment

Remote/hosted session via T3 Connect (not the desktop app directly). Same underlying crash class as #11074/#12244.

Logs or stack traces

T3 Code (Alpha) 0.0.42
Error: CodeView.addItem: duplicate id "agents/foo.mdagents/foo.md"
    at e.appendItemsInternal (t3code://app/assets/diffFileContents-CFYwckRB.js:1:18149)
    at e.setItems (t3code://app/assets/diffFileContents-CFYwckRB.js:1:17760)
    at t3code://app/assets/diffFileContents-CFYwckRB.js:1:49631

Workaround

Split the type change into two separate commits (delete the old path, then add the new path in a following commit) instead of a single same-path type-change commit. This avoids the collapsed same-path diff record entirely.

Related issues

• [Bug]: CodeView crashes with duplicate id when a regular file becomes a symlink #11074 - original report and fix for this exact buildFileDiffIdentityKey() collision (closed Completed 2026-09-18).
• [Bug]: Same-path file type changes crash diff view with duplicate CodeView ID #12244 - duplicate of [Bug]: CodeView crashes with duplicate id when a regular file becomes a symlink #11074.

Not a duplicate: both prior reports were against the desktop app and predate or coincide with the fix landing. This reproduces afterward, on 0.0.42, through a remote/hosted T3 Connect session specifically - which #11074's own investigation flagged as a separate code path ("the same collision would hit working-tree / branch diffs in the same panel") that may not have received the same fix.

[juliusmarminge]

Triage

Same crash as #11074, still present on Alpha 0.0.42 because that release does not contain the fix. Not a post-#11075 regression, and not #12887.

What the report matches

CodeView.addItem: duplicate id "agents/foo.mdagents/foo.md" is the pre-fix identity. On 0.0.42, buildFileDiffIdentityKey() in apps/web/src/lib/diffRendering.ts is only previous path + current path (path\0path). A same-path type change is two patch blocks (delete the regular file, add the symlink), both resolve to that key, and Pierre throws. The NUL separator is invisible, so the message prints as agents/foo.mdagents/foo.md.

#11075 (merged 2026-09-18) appends the change type, so those halves become …\0deleted and …\0new. A build with that fix would not throw this id. The reported id has no type suffix.

Why 0.0.42 cannot be a regression

• v0.0.42 is commit 719a76ca (2026-09-15) and is still the latest stable release (published 2026-09-16). git merge-base --is-ancestor 9ea9c3d5d v0.0.42 is false. The 0.0.42 function is the path-only key above.
• The first tags that contain 9ea9c3d5d are v0.0.43-preview.20260919.1937 and v0.0.43-nightly.20260919.1948. Nightlies from that build through v0.0.43-nightly.20260922.2083 include it. [Bug]: Same-path file type changes crash diff view with duplicate CodeView ID #12244’s diffFileContents-DyQONavv.js is v0.0.43-nightly.20260917.1851, which is also before the fix.
• diffFileContents-CFYwckRB.js is the 0.0.42 desktop bundle. [Bug]: Opening PR diff crashes with file/directory path collision #12887 is that same asset hash and version, with a different throw (Path collides with an existing file while creating directory "office" in the file-tree model). A different hash from [Bug]: Same-path file type changes crash diff view with duplicate CodeView ID #12244 only means a different pre-fix build.

Remote T3 Connect is not a second keying path

The stack is t3code://app/assets/…. That is the desktop renderer, served from the packaged client (clientAssetsDir over t3code://app), including when the environment on the other side is a remote T3 Connect session. Hosted web (app.t3.codes) would show an https:// asset URL. Working-tree and commit diffs both go through DiffPanel → buildFileDiffIdentityKey. The working-tree / branch-diff collision called out on #11074 was fixed in that same function in #11075. The PR tab keys by Pierre cacheKey and was not this throw.

Not #12887

#12887 is an open file-versus-directory prefix collision in the diff sidebar tree. #11075 already folds a same-path delete+add into one tree row. Different error, different site.

Tracking stays on #11074 / #11075. Stable will keep crashing on this patch until the next stable release; nightlies since 2026-09-19 already have the fix. On desktop: Settings → About → Update track → Nightly, then check for updates. If a nightly at or after 0.0.43-nightly.20260919.1948 still throws, a new report with that build’s full error text (version line plus stack) would be a different bug.