[Bug]: Native Windows image-read activity prefixes external absolute paths with the project name #27308

Before submitting

• I searched existing issues and PRs.
• I included a native Windows reproduction and a deterministic formatter reproduction.

Exact prior work: #13414 describes the same repo/C:/... display bug and proposes a fix. It is closed without merging, so this issue tracks the still-reproducible behavior in a current Windows nightly. I did not find a dedicated existing issue for this formatter bug.

Area

apps/web, visible in the Windows desktop chat activity log.

Steps to reproduce

1. Run T3 Code desktop and its backend natively on Windows, with a thread in a project such as C:/work/project. WSL is not involved.
2. Create an image outside that project, for example C:/tmp/image.png.
3. Ask the agent to inspect that file using its image/file-read tool.
4. Expand the read/image-view activity and inspect the path in its heading.

A live example was inspected in the installed Windows desktop app: a Claude Code image read of C:/tmp/bc2.png displayed Read pv-assets/C:/tmp/bc2.png, where pv-assets is the workspace basename. The preview caption underneath retained C:/tmp/bc2.png. Another read of C:/tmp/bc.png showed the same prefixing.

The initial user report described the heading as "Viewing project/C:/tmp/image.png"; the directly observed heading in this build uses "Read".

Expected behavior

An absolute Windows path outside the workspace remains an absolute path in the activity heading, such as Read C:/tmp/image.png. It should not acquire the workspace basename.

Actual behavior

The displayed path becomes project/C:/tmp/image.png, as though the drive-qualified path were relative to the workspace.

Deterministic reproduction

I extracted the actual formatter and path helper functions from the installed client bundles in server.asar and evaluated them with Node on the Windows host. Only Effect's generic pipe operation was supplied by the harness; path parsing, Windows-path predicates and display formatting used the extracted production functions.

With workspace root C:/work/project, the installed formatter produces:

Both external Windows separator forms reproducibly fail; the in-workspace and POSIX examples provide controls.

The equivalent focused reproduction in a repository test is:

expect(
  formatWorkspaceRelativePath("C:/tmp/image.png", "C:/work/project"),
).toBe("C:/tmp/image.png");
// Current result: "project/C:/tmp/image.png"

Code path

The installed implementation matches the relevant logic in filePathDisplay.ts on main at 36dac688a17c:

} else if (!normalizedPath.startsWith("/")) {
  const relativePath = stripRelativePrefixes(normalizedPath);
  displayPath = pathForCompare.startsWith(workspaceLabelWithSeparator)
    ? normalizedPath
    : `${workspaceLabel}/${relativePath}`;
}

A drive-qualified external path does not start with /, so it enters the relative-path branch. The same file already imports isWindowsAbsolutePath, but that predicate is not used to guard this branch. #13414 proposed excluding Windows absolute paths here.

MessagesTimeline.logic.ts applies this formatter to read paths before building the activity label. Image-view activity is classified as a read in the shared tool-activity logic.

Image visibility and limits of this reproduction

In the directly inspected Claude Code example, the image rendered despite the incorrect heading, and the caption preserved the original absolute path. This reproduction therefore confirms incorrect display formatting, not that the provider attempted to open the prefixed path.

The user also reports another instance where the image did not display at all. That additional symptom has not been independently reproduced here, and a shared cause is unconfirmed. Related image-visibility reports include #20897 and #7555; this issue's demonstrated bug is the incorrect Windows path prefix.

Impact

Minor bug or occasional failure: misleading image/file-read paths make it difficult to verify what the agent inspected.

Version or commit

Installed desktop/server: 0.1.6-nightly.20261029.3892.
Upstream source inspected: 36dac688a17c6de1c6398e62d01546fb787c185b.

Environment

Native Windows x64, OS build 10.0.26200; T3 Code Nightly desktop with its local Windows backend. Direct UI example used Claude Code, model claude-opus-5-5. No WSL or remote Linux backend.

Related work

• fix(web): don't label Windows paths outside the workspace as relative #13414: exact formatter bug, closed without merging.
• [Bug]: Under WSL, a file link written as a Windows path fails to open #16365 / fix(server): Windows drive paths open under WSL #26030: a separate WSL backend resolution problem. This report reproduces without WSL.
• [Bug]: Images and file links with Windows paths like C:\Users\me\.t3\... don't load #14261: Windows Markdown backslash escaping, a different failure mechanism.

Workaround

For an image inside the project, use its workspace-relative path. For an external image, the original path in the expanded preview caption can be used to check the actual target; the incorrect heading remains.

Investigated and filed on the user's behalf with GPT-6.1 Sol through the Codex harness in T3 Code.