[Bug]: File links in agent output always resolve against the thread's project, not the repo the file is in

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. Register two projects in the same environment, for example /repos/app-a and /repos/app-b.
2. Open a thread in the app-a project.
3. Ask the agent about code in the other checkout, so it runs something like cd ../app-b && cat src/api/rules/categories.ts.
4. In its answer the agent refers to the file the way it read it, relative to where it was standing: `rules/categories.ts:7` or [categories.ts](rules/categories.ts).
5. Click the resulting file chip, or open its context menu and pick "Copy full path".

Expected behavior

The chip points at the file the agent actually read, in /repos/app-b.

Actual behavior

Every relative reference is joined onto the thread's own project root, so the chip resolves to /repos/app-a/rules/categories.ts. That file does not exist. Clicking opens the wrong path, and "Copy full path" copies it.

This happens for both markdown links and auto-linked inline code spans. It is the same for any agent that steps outside the thread's workspace during a turn.

Impact

Minor bug or occasional failure

Version or commit

main @ latest

Environment

macOS, web client (also applies to desktop, which wraps web). Mobile does not render these chips.

Logs or stack traces

N/A

Workaround

Ask the agent for absolute paths. Absolute references link correctly.

Notes

resolveMarkdownFileLinkTarget in apps/web/src/markdown-links.ts ends with resolvePathLinkTarget(pathWithPosition, cwd), where cwd is always the thread's project root. Nothing downstream checks whether the resulting path exists, so a relative reference from another checkout silently produces a link into the wrong repo.

The prose itself carries no repo, and the agent's real working directory came from a cd inside a Bash call, which is not tracked. Resolving this properly seems to need an existence check against the environment's other project roots, most likely at click time so chat rendering stays free.

Start in apps/web/src/markdown-links.ts, especially resolveMarkdownFileLinkTarget and its call to resolvePathLinkTarget(pathWithPosition, cwd), then trace how file chips handle clicks and "Copy full path." Reproduce the two-project case and verify that relative markdown links and inline code references resolve to the project containing the file, while absolute references continue to work.