Render saved screenshots and recordings in chat markdown

[juliusmarminge]

Summary

• Add secure asset access for saved screenshots, videos, and browser artifacts.
• Support saving preview screenshots to workspace paths or browser artifact storage.
• Render saved media directly in chat markdown.
• Extend preview recording and snapshot contracts and handlers.
• Tighten pull request head matching and simplify related UI logic.

Testing

• Added focused coverage for asset URL issuance and browser artifact validation.
• Added MCP snapshot save-path and artifact persistence tests.
• Passed focused asset, MCP, timeline, and session tests plus target package typechecks, targeted lint, and a web production build.
• Verified signed workspace images inline and expanded in the real web client.

---

Note

High Risk
Changes signed asset authorization, filesystem containment, and MCP-driven writes into the workspace and browser-artifacts store—security-sensitive paths with extensive symlink handling that must stay correct on every request.

Overview
Chat and MCP preview flows can now show saved screenshots and recordings inline instead of leaving paths as plain text.

Signed asset serving adds browser-artifact and thread-image resources, treats workspace videos like images (exact-file tokens), and tightens containment (real .. segments only, not names like ..screenshots). Browser artifacts and thread images are re-canonicalized on every fetch so post-issuance symlink swaps do not keep serving the old target.

preview_snapshot can persist PNGs with save:true into browser-artifacts or with savePath into the thread workspace; workspace writes validate extensions, traversal, and directory/file symlinks before writing. Tool metadata reflects that snapshot is no longer read-only/idempotent when saving.

Thread UI maps Codex image view/generation activities to local paths (pruning huge base64 payloads), derives work-log imagePath/imageActivityId, and shows deduplicated galleries on the terminal assistant message or as image-output rows once the turn settles.

Chat markdown renders img/video via MarkdownMedia, resolving workspace-relative paths and absolute browser-artifacts paths to signed URLs (including Windows drive path sanitization).

^{Reviewed by Cursor Bugbot for commit 58f9832. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Render saved screenshots and recordings in chat markdown with asset URL resolution

• Adds save/savePath parameters to the preview_snapshot MCP tool, writing screenshots to either a workspace-relative path or a dedicated browser-artifacts directory; returns savedScreenshotPath in the response.
• Extends the chat markdown renderer to display <img> and <video> elements via a new MarkdownMedia component that resolves workspace-relative and absolute paths to signed asset URLs.
• Introduces browser-artifact and thread-image asset resource kinds end-to-end: new claim types in the JWT schema, issuance and re-resolution logic in AssetAccess, and a new assetsCreateUrl WS handler branch for thread-image.
• Adds image_view support to the messages timeline: appendImageOutputRows groups deduplicated image thumbnails per turn into inline galleries attached to assistant messages or emitted as standalone rows.
• Adds a Windows drive path rehype plugin (ChatMarkdown.tsx) that prefixes C:\... srcs with / before sanitization so they survive the sanitize pass.
• Risk: browser-artifact and thread-image claims are re-resolved on every asset request (realpath + stat), adding filesystem I/O to each signed URL fetch.

^{Macroscope summarized 58f9832.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c82b6be7-c79a-4e7b-a19b-79b6c103f8ee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/render-chat-media

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Effect service review: one convention issue found regarding error cause preservation. See inline comment.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

3 blocking correctness issues found. This PR introduces a new feature for rendering screenshots/recordings in chat with significant new code paths. Two unresolved Critical security comments identify TOCTOU race conditions and hard link vulnerabilities in the file-writing logic that require human review before merging.

^{You can customize Macroscope's approvability policy. Learn more.}

[macroscopeapp]

One finding on the new PreviewAutomationScreenshotSaveError shape; everything else (namespace imports, environment-based dependency acquisition for ServerConfig/ProjectionSnapshotQuery/WorkspacePaths/FileSystem/Path, Effect.catchTags usage, Schema.TaggedErrorClass errors in packages/contracts/src/assets.ts) matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:214

saveSnapshotScreenshot checks whether the destination is a symlink with readLink (line 214), then writes to it in a separate writeScreenshotFile call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing writeFile to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the realPath parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with O_NOFOLLOW | O_CREAT | O_EXCL) rather than verifying the path is not a symlink beforehand.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 214:
`saveSnapshotScreenshot` checks whether the destination is a symlink with `readLink` (line 214), then writes to it in a separate `writeScreenshotFile` call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing `writeFile` to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the `realPath` parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with `O_NOFOLLOW | O_CREAT | O_EXCL`) rather than verifying the path is not a symlink beforehand.

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:219

saveSnapshotScreenshot rejects symlinks at the destination but does not reject hard links. A workspace process can create savePath as a hard link to a file outside the workspace, and writeScreenshotFile then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The readLink check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via stat) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 219:
`saveSnapshotScreenshot` rejects symlinks at the destination but does not reject hard links. A workspace process can create `savePath` as a hard link to a file outside the workspace, and `writeScreenshotFile` then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The `readLink` check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via `stat`) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

[macroscopeapp]

🟢 Lowchat/MarkdownMedia.tsx:37

mediaFileName only treats / as a path separator, so Windows-style sources like /C:\repo\clip.mp4 (produced by the Windows-drive-path escaping) return the full path C:\repo\clip.mp4 instead of just clip.mp4. When there is no nonempty alt text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both / and \ so Windows backslash separators are handled.

Suggested change

	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constbasename=withoutQuery.slice(withoutQuery.lastIndexOf("/")+1);
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}
	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constlastSep=Math.max(withoutQuery.lastIndexOf("/"),withoutQuery.lastIndexOf("\\"));
	constbasename=lastSep>=0 ? withoutQuery.slice(lastSep+1) : withoutQuery;
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MarkdownMedia.tsx around lines 37-41:
`mediaFileName` only treats `/` as a path separator, so Windows-style sources like `/C:\repo\clip.mp4` (produced by the Windows-drive-path escaping) return the full path `C:\repo\clip.mp4` instead of just `clip.mp4`. When there is no nonempty `alt` text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both `/` and `\` so Windows backslash separators are handled.

[macroscopeapp]

🟡 Mediumchat/MessagesTimeline.tsx:1966

Each thumbnail calls onImageExpand with images containing only its own loadedUrl, so the expanded viewer cannot navigate to other images in the same gallery. The images array should include all loaded thumbnails and index should point to the clicked one, so the preview can show the full gallery as expected.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MessagesTimeline.tsx around line 1966:
Each thumbnail calls `onImageExpand` with `images` containing only its own `loadedUrl`, so the expanded viewer cannot navigate to other images in the same gallery. The `images` array should include all loaded thumbnails and `index` should point to the clicked one, so the preview can show the full gallery as expected.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[cursor]

Command projection drops image paths

Medium Severity

For image_view activities, projectActivityPayload sets data.item from projectCommandData(data) ?? projectImageViewData(data). When the tool item includes any pruned command field (command, input.command, or result.command), command projection wins and image-view projection is skipped, so type, path, and savedPath never reach thread snapshots. Clients then derive no imagePath, so inline galleries and thread-image asset requests for those activities fail even though the full payload in persistence still carries the image path.

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[juliusmarminge]

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

[juliusmarminge]

Summary

• Add secure asset access for saved screenshots, videos, and browser artifacts.
• Support saving preview screenshots to workspace paths or browser artifact storage.
• Render saved media directly in chat markdown.
• Extend preview recording and snapshot contracts and handlers.
• Tighten pull request head matching and simplify related UI logic.

Testing

• Added focused coverage for asset URL issuance and browser artifact validation.
• Added MCP snapshot save-path and artifact persistence tests.
• Passed focused asset, MCP, timeline, and session tests plus target package typechecks, targeted lint, and a web production build.
• Verified signed workspace images inline and expanded in the real web client.

---

Note

High Risk
Changes signed asset authorization, filesystem containment, and MCP-driven writes into the workspace and browser-artifacts store—security-sensitive paths with extensive symlink handling that must stay correct on every request.

Overview
Chat and MCP preview flows can now show saved screenshots and recordings inline instead of leaving paths as plain text.

Signed asset serving adds browser-artifact and thread-image resources, treats workspace videos like images (exact-file tokens), and tightens containment (real .. segments only, not names like ..screenshots). Browser artifacts and thread images are re-canonicalized on every fetch so post-issuance symlink swaps do not keep serving the old target.

preview_snapshot can persist PNGs with save:true into browser-artifacts or with savePath into the thread workspace; workspace writes validate extensions, traversal, and directory/file symlinks before writing. Tool metadata reflects that snapshot is no longer read-only/idempotent when saving.

Thread UI maps Codex image view/generation activities to local paths (pruning huge base64 payloads), derives work-log imagePath/imageActivityId, and shows deduplicated galleries on the terminal assistant message or as image-output rows once the turn settles.

Chat markdown renders img/video via MarkdownMedia, resolving workspace-relative paths and absolute browser-artifacts paths to signed URLs (including Windows drive path sanitization).

^{Reviewed by Cursor Bugbot for commit 58f9832. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Render saved screenshots and recordings in chat markdown with asset URL resolution

• Adds save/savePath parameters to the preview_snapshot MCP tool, writing screenshots to either a workspace-relative path or a dedicated browser-artifacts directory; returns savedScreenshotPath in the response.
• Extends the chat markdown renderer to display <img> and <video> elements via a new MarkdownMedia component that resolves workspace-relative and absolute paths to signed asset URLs.
• Introduces browser-artifact and thread-image asset resource kinds end-to-end: new claim types in the JWT schema, issuance and re-resolution logic in AssetAccess, and a new assetsCreateUrl WS handler branch for thread-image.
• Adds image_view support to the messages timeline: appendImageOutputRows groups deduplicated image thumbnails per turn into inline galleries attached to assistant messages or emitted as standalone rows.
• Adds a Windows drive path rehype plugin (ChatMarkdown.tsx) that prefixes C:\... srcs with / before sanitization so they survive the sanitize pass.
• Risk: browser-artifact and thread-image claims are re-resolved on every asset request (realpath + stat), adding filesystem I/O to each signed URL fetch.

^{Macroscope summarized 58f9832.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c82b6be7-c79a-4e7b-a19b-79b6c103f8ee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/render-chat-media

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Effect service review: one convention issue found regarding error cause preservation. See inline comment.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

3 blocking correctness issues found. This PR introduces a new feature for rendering screenshots/recordings in chat with significant new code paths. Two unresolved Critical security comments identify TOCTOU race conditions and hard link vulnerabilities in the file-writing logic that require human review before merging.

^{You can customize Macroscope's approvability policy. Learn more.}

[macroscopeapp]

One finding on the new PreviewAutomationScreenshotSaveError shape; everything else (namespace imports, environment-based dependency acquisition for ServerConfig/ProjectionSnapshotQuery/WorkspacePaths/FileSystem/Path, Effect.catchTags usage, Schema.TaggedErrorClass errors in packages/contracts/src/assets.ts) matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:214

saveSnapshotScreenshot checks whether the destination is a symlink with readLink (line 214), then writes to it in a separate writeScreenshotFile call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing writeFile to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the realPath parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with O_NOFOLLOW | O_CREAT | O_EXCL) rather than verifying the path is not a symlink beforehand.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 214:
`saveSnapshotScreenshot` checks whether the destination is a symlink with `readLink` (line 214), then writes to it in a separate `writeScreenshotFile` call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing `writeFile` to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the `realPath` parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with `O_NOFOLLOW | O_CREAT | O_EXCL`) rather than verifying the path is not a symlink beforehand.

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:219

saveSnapshotScreenshot rejects symlinks at the destination but does not reject hard links. A workspace process can create savePath as a hard link to a file outside the workspace, and writeScreenshotFile then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The readLink check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via stat) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 219:
`saveSnapshotScreenshot` rejects symlinks at the destination but does not reject hard links. A workspace process can create `savePath` as a hard link to a file outside the workspace, and `writeScreenshotFile` then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The `readLink` check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via `stat`) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

[macroscopeapp]

🟢 Lowchat/MarkdownMedia.tsx:37

mediaFileName only treats / as a path separator, so Windows-style sources like /C:\repo\clip.mp4 (produced by the Windows-drive-path escaping) return the full path C:\repo\clip.mp4 instead of just clip.mp4. When there is no nonempty alt text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both / and \ so Windows backslash separators are handled.

Suggested change

	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constbasename=withoutQuery.slice(withoutQuery.lastIndexOf("/")+1);
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}
	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constlastSep=Math.max(withoutQuery.lastIndexOf("/"),withoutQuery.lastIndexOf("\\"));
	constbasename=lastSep>=0 ? withoutQuery.slice(lastSep+1) : withoutQuery;
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MarkdownMedia.tsx around lines 37-41:
`mediaFileName` only treats `/` as a path separator, so Windows-style sources like `/C:\repo\clip.mp4` (produced by the Windows-drive-path escaping) return the full path `C:\repo\clip.mp4` instead of just `clip.mp4`. When there is no nonempty `alt` text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both `/` and `\` so Windows backslash separators are handled.

[macroscopeapp]

🟡 Mediumchat/MessagesTimeline.tsx:1966

Each thumbnail calls onImageExpand with images containing only its own loadedUrl, so the expanded viewer cannot navigate to other images in the same gallery. The images array should include all loaded thumbnails and index should point to the clicked one, so the preview can show the full gallery as expected.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MessagesTimeline.tsx around line 1966:
Each thumbnail calls `onImageExpand` with `images` containing only its own `loadedUrl`, so the expanded viewer cannot navigate to other images in the same gallery. The `images` array should include all loaded thumbnails and `index` should point to the clicked one, so the preview can show the full gallery as expected.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[cursor]

Command projection drops image paths

Medium Severity

For image_view activities, projectActivityPayload sets data.item from projectCommandData(data) ?? projectImageViewData(data). When the tool item includes any pruned command field (command, input.command, or result.command), command projection wins and image-view projection is skipped, so type, path, and savedPath never reach thread snapshots. Clients then derive no imagePath, so inline galleries and thread-image asset requests for those activities fail even though the full payload in persistence still carries the image path.

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[juliusmarminge]

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

[juliusmarminge]

Summary

• Add secure asset access for saved screenshots, videos, and browser artifacts.
• Support saving preview screenshots to workspace paths or browser artifact storage.
• Render saved media directly in chat markdown.
• Extend preview recording and snapshot contracts and handlers.
• Tighten pull request head matching and simplify related UI logic.

Testing

• Added focused coverage for asset URL issuance and browser artifact validation.
• Added MCP snapshot save-path and artifact persistence tests.
• Passed focused asset, MCP, timeline, and session tests plus target package typechecks, targeted lint, and a web production build.
• Verified signed workspace images inline and expanded in the real web client.

---

Note

High Risk
Changes signed asset authorization, filesystem containment, and MCP-driven writes into the workspace and browser-artifacts store—security-sensitive paths with extensive symlink handling that must stay correct on every request.

Overview
Chat and MCP preview flows can now show saved screenshots and recordings inline instead of leaving paths as plain text.

Signed asset serving adds browser-artifact and thread-image resources, treats workspace videos like images (exact-file tokens), and tightens containment (real .. segments only, not names like ..screenshots). Browser artifacts and thread images are re-canonicalized on every fetch so post-issuance symlink swaps do not keep serving the old target.

preview_snapshot can persist PNGs with save:true into browser-artifacts or with savePath into the thread workspace; workspace writes validate extensions, traversal, and directory/file symlinks before writing. Tool metadata reflects that snapshot is no longer read-only/idempotent when saving.

Thread UI maps Codex image view/generation activities to local paths (pruning huge base64 payloads), derives work-log imagePath/imageActivityId, and shows deduplicated galleries on the terminal assistant message or as image-output rows once the turn settles.

Chat markdown renders img/video via MarkdownMedia, resolving workspace-relative paths and absolute browser-artifacts paths to signed URLs (including Windows drive path sanitization).

^{Reviewed by Cursor Bugbot for commit 58f9832. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Render saved screenshots and recordings in chat markdown with asset URL resolution

• Adds save/savePath parameters to the preview_snapshot MCP tool, writing screenshots to either a workspace-relative path or a dedicated browser-artifacts directory; returns savedScreenshotPath in the response.
• Extends the chat markdown renderer to display <img> and <video> elements via a new MarkdownMedia component that resolves workspace-relative and absolute paths to signed asset URLs.
• Introduces browser-artifact and thread-image asset resource kinds end-to-end: new claim types in the JWT schema, issuance and re-resolution logic in AssetAccess, and a new assetsCreateUrl WS handler branch for thread-image.
• Adds image_view support to the messages timeline: appendImageOutputRows groups deduplicated image thumbnails per turn into inline galleries attached to assistant messages or emitted as standalone rows.
• Adds a Windows drive path rehype plugin (ChatMarkdown.tsx) that prefixes C:\... srcs with / before sanitization so they survive the sanitize pass.
• Risk: browser-artifact and thread-image claims are re-resolved on every asset request (realpath + stat), adding filesystem I/O to each signed URL fetch.

^{Macroscope summarized 58f9832.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c82b6be7-c79a-4e7b-a19b-79b6c103f8ee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/render-chat-media

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Effect service review: one convention issue found regarding error cause preservation. See inline comment.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

3 blocking correctness issues found. This PR introduces a new feature for rendering screenshots/recordings in chat with significant new code paths. Two unresolved Critical security comments identify TOCTOU race conditions and hard link vulnerabilities in the file-writing logic that require human review before merging.

^{You can customize Macroscope's approvability policy. Learn more.}

[macroscopeapp]

One finding on the new PreviewAutomationScreenshotSaveError shape; everything else (namespace imports, environment-based dependency acquisition for ServerConfig/ProjectionSnapshotQuery/WorkspacePaths/FileSystem/Path, Effect.catchTags usage, Schema.TaggedErrorClass errors in packages/contracts/src/assets.ts) matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:214

saveSnapshotScreenshot checks whether the destination is a symlink with readLink (line 214), then writes to it in a separate writeScreenshotFile call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing writeFile to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the realPath parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with O_NOFOLLOW | O_CREAT | O_EXCL) rather than verifying the path is not a symlink beforehand.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 214:
`saveSnapshotScreenshot` checks whether the destination is a symlink with `readLink` (line 214), then writes to it in a separate `writeScreenshotFile` call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing `writeFile` to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the `realPath` parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with `O_NOFOLLOW | O_CREAT | O_EXCL`) rather than verifying the path is not a symlink beforehand.

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:219

saveSnapshotScreenshot rejects symlinks at the destination but does not reject hard links. A workspace process can create savePath as a hard link to a file outside the workspace, and writeScreenshotFile then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The readLink check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via stat) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 219:
`saveSnapshotScreenshot` rejects symlinks at the destination but does not reject hard links. A workspace process can create `savePath` as a hard link to a file outside the workspace, and `writeScreenshotFile` then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The `readLink` check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via `stat`) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

[macroscopeapp]

🟢 Lowchat/MarkdownMedia.tsx:37

mediaFileName only treats / as a path separator, so Windows-style sources like /C:\repo\clip.mp4 (produced by the Windows-drive-path escaping) return the full path C:\repo\clip.mp4 instead of just clip.mp4. When there is no nonempty alt text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both / and \ so Windows backslash separators are handled.

Suggested change

	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constbasename=withoutQuery.slice(withoutQuery.lastIndexOf("/")+1);
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}
	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constlastSep=Math.max(withoutQuery.lastIndexOf("/"),withoutQuery.lastIndexOf("\\"));
	constbasename=lastSep>=0 ? withoutQuery.slice(lastSep+1) : withoutQuery;
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MarkdownMedia.tsx around lines 37-41:
`mediaFileName` only treats `/` as a path separator, so Windows-style sources like `/C:\repo\clip.mp4` (produced by the Windows-drive-path escaping) return the full path `C:\repo\clip.mp4` instead of just `clip.mp4`. When there is no nonempty `alt` text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both `/` and `\` so Windows backslash separators are handled.

[macroscopeapp]

🟡 Mediumchat/MessagesTimeline.tsx:1966

Each thumbnail calls onImageExpand with images containing only its own loadedUrl, so the expanded viewer cannot navigate to other images in the same gallery. The images array should include all loaded thumbnails and index should point to the clicked one, so the preview can show the full gallery as expected.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MessagesTimeline.tsx around line 1966:
Each thumbnail calls `onImageExpand` with `images` containing only its own `loadedUrl`, so the expanded viewer cannot navigate to other images in the same gallery. The `images` array should include all loaded thumbnails and `index` should point to the clicked one, so the preview can show the full gallery as expected.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[cursor]

Command projection drops image paths

Medium Severity

For image_view activities, projectActivityPayload sets data.item from projectCommandData(data) ?? projectImageViewData(data). When the tool item includes any pruned command field (command, input.command, or result.command), command projection wins and image-view projection is skipped, so type, path, and savedPath never reach thread snapshots. Clients then derive no imagePath, so inline galleries and thread-image asset requests for those activities fail even though the full payload in persistence still carries the image path.

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[juliusmarminge]

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

[juliusmarminge]

Summary

• Add secure asset access for saved screenshots, videos, and browser artifacts.
• Support saving preview screenshots to workspace paths or browser artifact storage.
• Render saved media directly in chat markdown.
• Extend preview recording and snapshot contracts and handlers.
• Tighten pull request head matching and simplify related UI logic.

Testing

• Added focused coverage for asset URL issuance and browser artifact validation.
• Added MCP snapshot save-path and artifact persistence tests.
• Passed focused asset, MCP, timeline, and session tests plus target package typechecks, targeted lint, and a web production build.
• Verified signed workspace images inline and expanded in the real web client.

---

Note

High Risk
Changes signed asset authorization, filesystem containment, and MCP-driven writes into the workspace and browser-artifacts store—security-sensitive paths with extensive symlink handling that must stay correct on every request.

Overview
Chat and MCP preview flows can now show saved screenshots and recordings inline instead of leaving paths as plain text.

Signed asset serving adds browser-artifact and thread-image resources, treats workspace videos like images (exact-file tokens), and tightens containment (real .. segments only, not names like ..screenshots). Browser artifacts and thread images are re-canonicalized on every fetch so post-issuance symlink swaps do not keep serving the old target.

preview_snapshot can persist PNGs with save:true into browser-artifacts or with savePath into the thread workspace; workspace writes validate extensions, traversal, and directory/file symlinks before writing. Tool metadata reflects that snapshot is no longer read-only/idempotent when saving.

Thread UI maps Codex image view/generation activities to local paths (pruning huge base64 payloads), derives work-log imagePath/imageActivityId, and shows deduplicated galleries on the terminal assistant message or as image-output rows once the turn settles.

Chat markdown renders img/video via MarkdownMedia, resolving workspace-relative paths and absolute browser-artifacts paths to signed URLs (including Windows drive path sanitization).

^{Reviewed by Cursor Bugbot for commit 58f9832. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Render saved screenshots and recordings in chat markdown with asset URL resolution

• Adds save/savePath parameters to the preview_snapshot MCP tool, writing screenshots to either a workspace-relative path or a dedicated browser-artifacts directory; returns savedScreenshotPath in the response.
• Extends the chat markdown renderer to display <img> and <video> elements via a new MarkdownMedia component that resolves workspace-relative and absolute paths to signed asset URLs.
• Introduces browser-artifact and thread-image asset resource kinds end-to-end: new claim types in the JWT schema, issuance and re-resolution logic in AssetAccess, and a new assetsCreateUrl WS handler branch for thread-image.
• Adds image_view support to the messages timeline: appendImageOutputRows groups deduplicated image thumbnails per turn into inline galleries attached to assistant messages or emitted as standalone rows.
• Adds a Windows drive path rehype plugin (ChatMarkdown.tsx) that prefixes C:\... srcs with / before sanitization so they survive the sanitize pass.
• Risk: browser-artifact and thread-image claims are re-resolved on every asset request (realpath + stat), adding filesystem I/O to each signed URL fetch.

^{Macroscope summarized 58f9832.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c82b6be7-c79a-4e7b-a19b-79b6c103f8ee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/render-chat-media

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Effect service review: one convention issue found regarding error cause preservation. See inline comment.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

3 blocking correctness issues found. This PR introduces a new feature for rendering screenshots/recordings in chat with significant new code paths. Two unresolved Critical security comments identify TOCTOU race conditions and hard link vulnerabilities in the file-writing logic that require human review before merging.

^{You can customize Macroscope's approvability policy. Learn more.}

[macroscopeapp]

One finding on the new PreviewAutomationScreenshotSaveError shape; everything else (namespace imports, environment-based dependency acquisition for ServerConfig/ProjectionSnapshotQuery/WorkspacePaths/FileSystem/Path, Effect.catchTags usage, Schema.TaggedErrorClass errors in packages/contracts/src/assets.ts) matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:214

saveSnapshotScreenshot checks whether the destination is a symlink with readLink (line 214), then writes to it in a separate writeScreenshotFile call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing writeFile to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the realPath parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with O_NOFOLLOW | O_CREAT | O_EXCL) rather than verifying the path is not a symlink beforehand.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 214:
`saveSnapshotScreenshot` checks whether the destination is a symlink with `readLink` (line 214), then writes to it in a separate `writeScreenshotFile` call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing `writeFile` to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the `realPath` parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with `O_NOFOLLOW | O_CREAT | O_EXCL`) rather than verifying the path is not a symlink beforehand.

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:219

saveSnapshotScreenshot rejects symlinks at the destination but does not reject hard links. A workspace process can create savePath as a hard link to a file outside the workspace, and writeScreenshotFile then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The readLink check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via stat) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 219:
`saveSnapshotScreenshot` rejects symlinks at the destination but does not reject hard links. A workspace process can create `savePath` as a hard link to a file outside the workspace, and `writeScreenshotFile` then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The `readLink` check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via `stat`) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

[macroscopeapp]

🟢 Lowchat/MarkdownMedia.tsx:37

mediaFileName only treats / as a path separator, so Windows-style sources like /C:\repo\clip.mp4 (produced by the Windows-drive-path escaping) return the full path C:\repo\clip.mp4 instead of just clip.mp4. When there is no nonempty alt text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both / and \ so Windows backslash separators are handled.

Suggested change

	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constbasename=withoutQuery.slice(withoutQuery.lastIndexOf("/")+1);
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}
	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constlastSep=Math.max(withoutQuery.lastIndexOf("/"),withoutQuery.lastIndexOf("\\"));
	constbasename=lastSep>=0 ? withoutQuery.slice(lastSep+1) : withoutQuery;
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MarkdownMedia.tsx around lines 37-41:
`mediaFileName` only treats `/` as a path separator, so Windows-style sources like `/C:\repo\clip.mp4` (produced by the Windows-drive-path escaping) return the full path `C:\repo\clip.mp4` instead of just `clip.mp4`. When there is no nonempty `alt` text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both `/` and `\` so Windows backslash separators are handled.

[macroscopeapp]

🟡 Mediumchat/MessagesTimeline.tsx:1966

Each thumbnail calls onImageExpand with images containing only its own loadedUrl, so the expanded viewer cannot navigate to other images in the same gallery. The images array should include all loaded thumbnails and index should point to the clicked one, so the preview can show the full gallery as expected.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MessagesTimeline.tsx around line 1966:
Each thumbnail calls `onImageExpand` with `images` containing only its own `loadedUrl`, so the expanded viewer cannot navigate to other images in the same gallery. The `images` array should include all loaded thumbnails and `index` should point to the clicked one, so the preview can show the full gallery as expected.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[cursor]

Command projection drops image paths

Medium Severity

For image_view activities, projectActivityPayload sets data.item from projectCommandData(data) ?? projectImageViewData(data). When the tool item includes any pruned command field (command, input.command, or result.command), command projection wins and image-view projection is skipped, so type, path, and savedPath never reach thread snapshots. Clients then derive no imagePath, so inline galleries and thread-image asset requests for those activities fail even though the full payload in persistence still carries the image path.

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[juliusmarminge]

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

[juliusmarminge]

Summary

• Add secure asset access for saved screenshots, videos, and browser artifacts.
• Support saving preview screenshots to workspace paths or browser artifact storage.
• Render saved media directly in chat markdown.
• Extend preview recording and snapshot contracts and handlers.
• Tighten pull request head matching and simplify related UI logic.

Testing

• Added focused coverage for asset URL issuance and browser artifact validation.
• Added MCP snapshot save-path and artifact persistence tests.
• Passed focused asset, MCP, timeline, and session tests plus target package typechecks, targeted lint, and a web production build.
• Verified signed workspace images inline and expanded in the real web client.

---

Note

High Risk
Changes signed asset authorization, filesystem containment, and MCP-driven writes into the workspace and browser-artifacts store—security-sensitive paths with extensive symlink handling that must stay correct on every request.

Overview
Chat and MCP preview flows can now show saved screenshots and recordings inline instead of leaving paths as plain text.

Signed asset serving adds browser-artifact and thread-image resources, treats workspace videos like images (exact-file tokens), and tightens containment (real .. segments only, not names like ..screenshots). Browser artifacts and thread images are re-canonicalized on every fetch so post-issuance symlink swaps do not keep serving the old target.

preview_snapshot can persist PNGs with save:true into browser-artifacts or with savePath into the thread workspace; workspace writes validate extensions, traversal, and directory/file symlinks before writing. Tool metadata reflects that snapshot is no longer read-only/idempotent when saving.

Thread UI maps Codex image view/generation activities to local paths (pruning huge base64 payloads), derives work-log imagePath/imageActivityId, and shows deduplicated galleries on the terminal assistant message or as image-output rows once the turn settles.

Chat markdown renders img/video via MarkdownMedia, resolving workspace-relative paths and absolute browser-artifacts paths to signed URLs (including Windows drive path sanitization).

^{Reviewed by Cursor Bugbot for commit 58f9832. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Render saved screenshots and recordings in chat markdown with asset URL resolution

• Adds save/savePath parameters to the preview_snapshot MCP tool, writing screenshots to either a workspace-relative path or a dedicated browser-artifacts directory; returns savedScreenshotPath in the response.
• Extends the chat markdown renderer to display <img> and <video> elements via a new MarkdownMedia component that resolves workspace-relative and absolute paths to signed asset URLs.
• Introduces browser-artifact and thread-image asset resource kinds end-to-end: new claim types in the JWT schema, issuance and re-resolution logic in AssetAccess, and a new assetsCreateUrl WS handler branch for thread-image.
• Adds image_view support to the messages timeline: appendImageOutputRows groups deduplicated image thumbnails per turn into inline galleries attached to assistant messages or emitted as standalone rows.
• Adds a Windows drive path rehype plugin (ChatMarkdown.tsx) that prefixes C:\... srcs with / before sanitization so they survive the sanitize pass.
• Risk: browser-artifact and thread-image claims are re-resolved on every asset request (realpath + stat), adding filesystem I/O to each signed URL fetch.

^{Macroscope summarized 58f9832.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c82b6be7-c79a-4e7b-a19b-79b6c103f8ee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/render-chat-media

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Effect service review: one convention issue found regarding error cause preservation. See inline comment.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

3 blocking correctness issues found. This PR introduces a new feature for rendering screenshots/recordings in chat with significant new code paths. Two unresolved Critical security comments identify TOCTOU race conditions and hard link vulnerabilities in the file-writing logic that require human review before merging.

^{You can customize Macroscope's approvability policy. Learn more.}

[macroscopeapp]

One finding on the new PreviewAutomationScreenshotSaveError shape; everything else (namespace imports, environment-based dependency acquisition for ServerConfig/ProjectionSnapshotQuery/WorkspacePaths/FileSystem/Path, Effect.catchTags usage, Schema.TaggedErrorClass errors in packages/contracts/src/assets.ts) matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:214

saveSnapshotScreenshot checks whether the destination is a symlink with readLink (line 214), then writes to it in a separate writeScreenshotFile call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing writeFile to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the realPath parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with O_NOFOLLOW | O_CREAT | O_EXCL) rather than verifying the path is not a symlink beforehand.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 214:
`saveSnapshotScreenshot` checks whether the destination is a symlink with `readLink` (line 214), then writes to it in a separate `writeScreenshotFile` call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing `writeFile` to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the `realPath` parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with `O_NOFOLLOW | O_CREAT | O_EXCL`) rather than verifying the path is not a symlink beforehand.

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:219

saveSnapshotScreenshot rejects symlinks at the destination but does not reject hard links. A workspace process can create savePath as a hard link to a file outside the workspace, and writeScreenshotFile then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The readLink check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via stat) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 219:
`saveSnapshotScreenshot` rejects symlinks at the destination but does not reject hard links. A workspace process can create `savePath` as a hard link to a file outside the workspace, and `writeScreenshotFile` then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The `readLink` check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via `stat`) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

[macroscopeapp]

🟢 Lowchat/MarkdownMedia.tsx:37

mediaFileName only treats / as a path separator, so Windows-style sources like /C:\repo\clip.mp4 (produced by the Windows-drive-path escaping) return the full path C:\repo\clip.mp4 instead of just clip.mp4. When there is no nonempty alt text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both / and \ so Windows backslash separators are handled.

Suggested change

	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constbasename=withoutQuery.slice(withoutQuery.lastIndexOf("/")+1);
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}
	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constlastSep=Math.max(withoutQuery.lastIndexOf("/"),withoutQuery.lastIndexOf("\\"));
	constbasename=lastSep>=0 ? withoutQuery.slice(lastSep+1) : withoutQuery;
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MarkdownMedia.tsx around lines 37-41:
`mediaFileName` only treats `/` as a path separator, so Windows-style sources like `/C:\repo\clip.mp4` (produced by the Windows-drive-path escaping) return the full path `C:\repo\clip.mp4` instead of just `clip.mp4`. When there is no nonempty `alt` text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both `/` and `\` so Windows backslash separators are handled.

[macroscopeapp]

🟡 Mediumchat/MessagesTimeline.tsx:1966

Each thumbnail calls onImageExpand with images containing only its own loadedUrl, so the expanded viewer cannot navigate to other images in the same gallery. The images array should include all loaded thumbnails and index should point to the clicked one, so the preview can show the full gallery as expected.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MessagesTimeline.tsx around line 1966:
Each thumbnail calls `onImageExpand` with `images` containing only its own `loadedUrl`, so the expanded viewer cannot navigate to other images in the same gallery. The `images` array should include all loaded thumbnails and `index` should point to the clicked one, so the preview can show the full gallery as expected.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[cursor]

Command projection drops image paths

Medium Severity

For image_view activities, projectActivityPayload sets data.item from projectCommandData(data) ?? projectImageViewData(data). When the tool item includes any pruned command field (command, input.command, or result.command), command projection wins and image-view projection is skipped, so type, path, and savedPath never reach thread snapshots. Clients then derive no imagePath, so inline galleries and thread-image asset requests for those activities fail even though the full payload in persistence still carries the image path.

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[juliusmarminge]

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

[juliusmarminge]

Summary

• Add secure asset access for saved screenshots, videos, and browser artifacts.
• Support saving preview screenshots to workspace paths or browser artifact storage.
• Render saved media directly in chat markdown.
• Extend preview recording and snapshot contracts and handlers.
• Tighten pull request head matching and simplify related UI logic.

Testing

• Added focused coverage for asset URL issuance and browser artifact validation.
• Added MCP snapshot save-path and artifact persistence tests.
• Passed focused asset, MCP, timeline, and session tests plus target package typechecks, targeted lint, and a web production build.
• Verified signed workspace images inline and expanded in the real web client.

---

Note

High Risk
Changes signed asset authorization, filesystem containment, and MCP-driven writes into the workspace and browser-artifacts store—security-sensitive paths with extensive symlink handling that must stay correct on every request.

Overview
Chat and MCP preview flows can now show saved screenshots and recordings inline instead of leaving paths as plain text.

Signed asset serving adds browser-artifact and thread-image resources, treats workspace videos like images (exact-file tokens), and tightens containment (real .. segments only, not names like ..screenshots). Browser artifacts and thread images are re-canonicalized on every fetch so post-issuance symlink swaps do not keep serving the old target.

preview_snapshot can persist PNGs with save:true into browser-artifacts or with savePath into the thread workspace; workspace writes validate extensions, traversal, and directory/file symlinks before writing. Tool metadata reflects that snapshot is no longer read-only/idempotent when saving.

Thread UI maps Codex image view/generation activities to local paths (pruning huge base64 payloads), derives work-log imagePath/imageActivityId, and shows deduplicated galleries on the terminal assistant message or as image-output rows once the turn settles.

Chat markdown renders img/video via MarkdownMedia, resolving workspace-relative paths and absolute browser-artifacts paths to signed URLs (including Windows drive path sanitization).

^{Reviewed by Cursor Bugbot for commit 58f9832. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Render saved screenshots and recordings in chat markdown with asset URL resolution

• Adds save/savePath parameters to the preview_snapshot MCP tool, writing screenshots to either a workspace-relative path or a dedicated browser-artifacts directory; returns savedScreenshotPath in the response.
• Extends the chat markdown renderer to display <img> and <video> elements via a new MarkdownMedia component that resolves workspace-relative and absolute paths to signed asset URLs.
• Introduces browser-artifact and thread-image asset resource kinds end-to-end: new claim types in the JWT schema, issuance and re-resolution logic in AssetAccess, and a new assetsCreateUrl WS handler branch for thread-image.
• Adds image_view support to the messages timeline: appendImageOutputRows groups deduplicated image thumbnails per turn into inline galleries attached to assistant messages or emitted as standalone rows.
• Adds a Windows drive path rehype plugin (ChatMarkdown.tsx) that prefixes C:\... srcs with / before sanitization so they survive the sanitize pass.
• Risk: browser-artifact and thread-image claims are re-resolved on every asset request (realpath + stat), adding filesystem I/O to each signed URL fetch.

^{Macroscope summarized 58f9832.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c82b6be7-c79a-4e7b-a19b-79b6c103f8ee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/render-chat-media

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Effect service review: one convention issue found regarding error cause preservation. See inline comment.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

3 blocking correctness issues found. This PR introduces a new feature for rendering screenshots/recordings in chat with significant new code paths. Two unresolved Critical security comments identify TOCTOU race conditions and hard link vulnerabilities in the file-writing logic that require human review before merging.

^{You can customize Macroscope's approvability policy. Learn more.}

[macroscopeapp]

One finding on the new PreviewAutomationScreenshotSaveError shape; everything else (namespace imports, environment-based dependency acquisition for ServerConfig/ProjectionSnapshotQuery/WorkspacePaths/FileSystem/Path, Effect.catchTags usage, Schema.TaggedErrorClass errors in packages/contracts/src/assets.ts) matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:214

saveSnapshotScreenshot checks whether the destination is a symlink with readLink (line 214), then writes to it in a separate writeScreenshotFile call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing writeFile to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the realPath parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with O_NOFOLLOW | O_CREAT | O_EXCL) rather than verifying the path is not a symlink beforehand.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 214:
`saveSnapshotScreenshot` checks whether the destination is a symlink with `readLink` (line 214), then writes to it in a separate `writeScreenshotFile` call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing `writeFile` to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the `realPath` parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with `O_NOFOLLOW | O_CREAT | O_EXCL`) rather than verifying the path is not a symlink beforehand.

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:219

saveSnapshotScreenshot rejects symlinks at the destination but does not reject hard links. A workspace process can create savePath as a hard link to a file outside the workspace, and writeScreenshotFile then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The readLink check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via stat) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 219:
`saveSnapshotScreenshot` rejects symlinks at the destination but does not reject hard links. A workspace process can create `savePath` as a hard link to a file outside the workspace, and `writeScreenshotFile` then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The `readLink` check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via `stat`) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

[macroscopeapp]

🟢 Lowchat/MarkdownMedia.tsx:37

mediaFileName only treats / as a path separator, so Windows-style sources like /C:\repo\clip.mp4 (produced by the Windows-drive-path escaping) return the full path C:\repo\clip.mp4 instead of just clip.mp4. When there is no nonempty alt text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both / and \ so Windows backslash separators are handled.

Suggested change

	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constbasename=withoutQuery.slice(withoutQuery.lastIndexOf("/")+1);
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}
	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constlastSep=Math.max(withoutQuery.lastIndexOf("/"),withoutQuery.lastIndexOf("\\"));
	constbasename=lastSep>=0 ? withoutQuery.slice(lastSep+1) : withoutQuery;
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MarkdownMedia.tsx around lines 37-41:
`mediaFileName` only treats `/` as a path separator, so Windows-style sources like `/C:\repo\clip.mp4` (produced by the Windows-drive-path escaping) return the full path `C:\repo\clip.mp4` instead of just `clip.mp4`. When there is no nonempty `alt` text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both `/` and `\` so Windows backslash separators are handled.

[macroscopeapp]

🟡 Mediumchat/MessagesTimeline.tsx:1966

Each thumbnail calls onImageExpand with images containing only its own loadedUrl, so the expanded viewer cannot navigate to other images in the same gallery. The images array should include all loaded thumbnails and index should point to the clicked one, so the preview can show the full gallery as expected.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MessagesTimeline.tsx around line 1966:
Each thumbnail calls `onImageExpand` with `images` containing only its own `loadedUrl`, so the expanded viewer cannot navigate to other images in the same gallery. The `images` array should include all loaded thumbnails and `index` should point to the clicked one, so the preview can show the full gallery as expected.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[cursor]

Command projection drops image paths

Medium Severity

For image_view activities, projectActivityPayload sets data.item from projectCommandData(data) ?? projectImageViewData(data). When the tool item includes any pruned command field (command, input.command, or result.command), command projection wins and image-view projection is skipped, so type, path, and savedPath never reach thread snapshots. Clients then derive no imagePath, so inline galleries and thread-image asset requests for those activities fail even though the full payload in persistence still carries the image path.

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[juliusmarminge]

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

[juliusmarminge]

Summary

• Add secure asset access for saved screenshots, videos, and browser artifacts.
• Support saving preview screenshots to workspace paths or browser artifact storage.
• Render saved media directly in chat markdown.
• Extend preview recording and snapshot contracts and handlers.
• Tighten pull request head matching and simplify related UI logic.

Testing

• Added focused coverage for asset URL issuance and browser artifact validation.
• Added MCP snapshot save-path and artifact persistence tests.
• Passed focused asset, MCP, timeline, and session tests plus target package typechecks, targeted lint, and a web production build.
• Verified signed workspace images inline and expanded in the real web client.

---

Note

High Risk
Changes signed asset authorization, filesystem containment, and MCP-driven writes into the workspace and browser-artifacts store—security-sensitive paths with extensive symlink handling that must stay correct on every request.

Overview
Chat and MCP preview flows can now show saved screenshots and recordings inline instead of leaving paths as plain text.

Signed asset serving adds browser-artifact and thread-image resources, treats workspace videos like images (exact-file tokens), and tightens containment (real .. segments only, not names like ..screenshots). Browser artifacts and thread images are re-canonicalized on every fetch so post-issuance symlink swaps do not keep serving the old target.

preview_snapshot can persist PNGs with save:true into browser-artifacts or with savePath into the thread workspace; workspace writes validate extensions, traversal, and directory/file symlinks before writing. Tool metadata reflects that snapshot is no longer read-only/idempotent when saving.

Thread UI maps Codex image view/generation activities to local paths (pruning huge base64 payloads), derives work-log imagePath/imageActivityId, and shows deduplicated galleries on the terminal assistant message or as image-output rows once the turn settles.

Chat markdown renders img/video via MarkdownMedia, resolving workspace-relative paths and absolute browser-artifacts paths to signed URLs (including Windows drive path sanitization).

^{Reviewed by Cursor Bugbot for commit 58f9832. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Render saved screenshots and recordings in chat markdown with asset URL resolution

• Adds save/savePath parameters to the preview_snapshot MCP tool, writing screenshots to either a workspace-relative path or a dedicated browser-artifacts directory; returns savedScreenshotPath in the response.
• Extends the chat markdown renderer to display <img> and <video> elements via a new MarkdownMedia component that resolves workspace-relative and absolute paths to signed asset URLs.
• Introduces browser-artifact and thread-image asset resource kinds end-to-end: new claim types in the JWT schema, issuance and re-resolution logic in AssetAccess, and a new assetsCreateUrl WS handler branch for thread-image.
• Adds image_view support to the messages timeline: appendImageOutputRows groups deduplicated image thumbnails per turn into inline galleries attached to assistant messages or emitted as standalone rows.
• Adds a Windows drive path rehype plugin (ChatMarkdown.tsx) that prefixes C:\... srcs with / before sanitization so they survive the sanitize pass.
• Risk: browser-artifact and thread-image claims are re-resolved on every asset request (realpath + stat), adding filesystem I/O to each signed URL fetch.

^{Macroscope summarized 58f9832.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c82b6be7-c79a-4e7b-a19b-79b6c103f8ee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/render-chat-media

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Effect service review: one convention issue found regarding error cause preservation. See inline comment.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

3 blocking correctness issues found. This PR introduces a new feature for rendering screenshots/recordings in chat with significant new code paths. Two unresolved Critical security comments identify TOCTOU race conditions and hard link vulnerabilities in the file-writing logic that require human review before merging.

^{You can customize Macroscope's approvability policy. Learn more.}

[macroscopeapp]

One finding on the new PreviewAutomationScreenshotSaveError shape; everything else (namespace imports, environment-based dependency acquisition for ServerConfig/ProjectionSnapshotQuery/WorkspacePaths/FileSystem/Path, Effect.catchTags usage, Schema.TaggedErrorClass errors in packages/contracts/src/assets.ts) matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:214

saveSnapshotScreenshot checks whether the destination is a symlink with readLink (line 214), then writes to it in a separate writeScreenshotFile call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing writeFile to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the realPath parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with O_NOFOLLOW | O_CREAT | O_EXCL) rather than verifying the path is not a symlink beforehand.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 214:
`saveSnapshotScreenshot` checks whether the destination is a symlink with `readLink` (line 214), then writes to it in a separate `writeScreenshotFile` call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing `writeFile` to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the `realPath` parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with `O_NOFOLLOW | O_CREAT | O_EXCL`) rather than verifying the path is not a symlink beforehand.

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:219

saveSnapshotScreenshot rejects symlinks at the destination but does not reject hard links. A workspace process can create savePath as a hard link to a file outside the workspace, and writeScreenshotFile then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The readLink check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via stat) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 219:
`saveSnapshotScreenshot` rejects symlinks at the destination but does not reject hard links. A workspace process can create `savePath` as a hard link to a file outside the workspace, and `writeScreenshotFile` then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The `readLink` check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via `stat`) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

[macroscopeapp]

🟢 Lowchat/MarkdownMedia.tsx:37

mediaFileName only treats / as a path separator, so Windows-style sources like /C:\repo\clip.mp4 (produced by the Windows-drive-path escaping) return the full path C:\repo\clip.mp4 instead of just clip.mp4. When there is no nonempty alt text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both / and \ so Windows backslash separators are handled.

Suggested change

	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constbasename=withoutQuery.slice(withoutQuery.lastIndexOf("/")+1);
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}
	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constlastSep=Math.max(withoutQuery.lastIndexOf("/"),withoutQuery.lastIndexOf("\\"));
	constbasename=lastSep>=0 ? withoutQuery.slice(lastSep+1) : withoutQuery;
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MarkdownMedia.tsx around lines 37-41:
`mediaFileName` only treats `/` as a path separator, so Windows-style sources like `/C:\repo\clip.mp4` (produced by the Windows-drive-path escaping) return the full path `C:\repo\clip.mp4` instead of just `clip.mp4`. When there is no nonempty `alt` text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both `/` and `\` so Windows backslash separators are handled.

[macroscopeapp]

🟡 Mediumchat/MessagesTimeline.tsx:1966

Each thumbnail calls onImageExpand with images containing only its own loadedUrl, so the expanded viewer cannot navigate to other images in the same gallery. The images array should include all loaded thumbnails and index should point to the clicked one, so the preview can show the full gallery as expected.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MessagesTimeline.tsx around line 1966:
Each thumbnail calls `onImageExpand` with `images` containing only its own `loadedUrl`, so the expanded viewer cannot navigate to other images in the same gallery. The `images` array should include all loaded thumbnails and `index` should point to the clicked one, so the preview can show the full gallery as expected.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[cursor]

Command projection drops image paths

Medium Severity

For image_view activities, projectActivityPayload sets data.item from projectCommandData(data) ?? projectImageViewData(data). When the tool item includes any pruned command field (command, input.command, or result.command), command projection wins and image-view projection is skipped, so type, path, and savedPath never reach thread snapshots. Clients then derive no imagePath, so inline galleries and thread-image asset requests for those activities fail even though the full payload in persistence still carries the image path.

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[juliusmarminge]

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

[juliusmarminge]

Summary

• Add secure asset access for saved screenshots, videos, and browser artifacts.
• Support saving preview screenshots to workspace paths or browser artifact storage.
• Render saved media directly in chat markdown.
• Extend preview recording and snapshot contracts and handlers.
• Tighten pull request head matching and simplify related UI logic.

Testing

• Added focused coverage for asset URL issuance and browser artifact validation.
• Added MCP snapshot save-path and artifact persistence tests.
• Passed focused asset, MCP, timeline, and session tests plus target package typechecks, targeted lint, and a web production build.
• Verified signed workspace images inline and expanded in the real web client.

---

Note

High Risk
Changes signed asset authorization, filesystem containment, and MCP-driven writes into the workspace and browser-artifacts store—security-sensitive paths with extensive symlink handling that must stay correct on every request.

Overview
Chat and MCP preview flows can now show saved screenshots and recordings inline instead of leaving paths as plain text.

Signed asset serving adds browser-artifact and thread-image resources, treats workspace videos like images (exact-file tokens), and tightens containment (real .. segments only, not names like ..screenshots). Browser artifacts and thread images are re-canonicalized on every fetch so post-issuance symlink swaps do not keep serving the old target.

preview_snapshot can persist PNGs with save:true into browser-artifacts or with savePath into the thread workspace; workspace writes validate extensions, traversal, and directory/file symlinks before writing. Tool metadata reflects that snapshot is no longer read-only/idempotent when saving.

Thread UI maps Codex image view/generation activities to local paths (pruning huge base64 payloads), derives work-log imagePath/imageActivityId, and shows deduplicated galleries on the terminal assistant message or as image-output rows once the turn settles.

Chat markdown renders img/video via MarkdownMedia, resolving workspace-relative paths and absolute browser-artifacts paths to signed URLs (including Windows drive path sanitization).

^{Reviewed by Cursor Bugbot for commit 58f9832. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Render saved screenshots and recordings in chat markdown with asset URL resolution

• Adds save/savePath parameters to the preview_snapshot MCP tool, writing screenshots to either a workspace-relative path or a dedicated browser-artifacts directory; returns savedScreenshotPath in the response.
• Extends the chat markdown renderer to display <img> and <video> elements via a new MarkdownMedia component that resolves workspace-relative and absolute paths to signed asset URLs.
• Introduces browser-artifact and thread-image asset resource kinds end-to-end: new claim types in the JWT schema, issuance and re-resolution logic in AssetAccess, and a new assetsCreateUrl WS handler branch for thread-image.
• Adds image_view support to the messages timeline: appendImageOutputRows groups deduplicated image thumbnails per turn into inline galleries attached to assistant messages or emitted as standalone rows.
• Adds a Windows drive path rehype plugin (ChatMarkdown.tsx) that prefixes C:\... srcs with / before sanitization so they survive the sanitize pass.
• Risk: browser-artifact and thread-image claims are re-resolved on every asset request (realpath + stat), adding filesystem I/O to each signed URL fetch.

^{Macroscope summarized 58f9832.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c82b6be7-c79a-4e7b-a19b-79b6c103f8ee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/render-chat-media

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Effect service review: one convention issue found regarding error cause preservation. See inline comment.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

3 blocking correctness issues found. This PR introduces a new feature for rendering screenshots/recordings in chat with significant new code paths. Two unresolved Critical security comments identify TOCTOU race conditions and hard link vulnerabilities in the file-writing logic that require human review before merging.

^{You can customize Macroscope's approvability policy. Learn more.}

[macroscopeapp]

One finding on the new PreviewAutomationScreenshotSaveError shape; everything else (namespace imports, environment-based dependency acquisition for ServerConfig/ProjectionSnapshotQuery/WorkspacePaths/FileSystem/Path, Effect.catchTags usage, Schema.TaggedErrorClass errors in packages/contracts/src/assets.ts) matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:214

saveSnapshotScreenshot checks whether the destination is a symlink with readLink (line 214), then writes to it in a separate writeScreenshotFile call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing writeFile to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the realPath parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with O_NOFOLLOW | O_CREAT | O_EXCL) rather than verifying the path is not a symlink beforehand.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 214:
`saveSnapshotScreenshot` checks whether the destination is a symlink with `readLink` (line 214), then writes to it in a separate `writeScreenshotFile` call (line 222). A concurrent process can replace the destination with a symlink after the check and before the write, causing `writeFile` to follow that symlink and overwrite an arbitrary file outside the workspace. The same check/use race exists for the `realPath` parent-directory checks. The preflight symlink checks do not close this TOCTOU gap — the final write needs no-follow/exclusive file-opening semantics (e.g. opening with `O_NOFOLLOW | O_CREAT | O_EXCL`) rather than verifying the path is not a symlink beforehand.

[macroscopeapp]

🔴 Criticalpreview/handlers.ts:219

saveSnapshotScreenshot rejects symlinks at the destination but does not reject hard links. A workspace process can create savePath as a hard link to a file outside the workspace, and writeScreenshotFile then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The readLink check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via stat) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/mcp/toolkits/preview/handlers.ts around line 219:
`saveSnapshotScreenshot` rejects symlinks at the destination but does not reject hard links. A workspace process can create `savePath` as a hard link to a file outside the workspace, and `writeScreenshotFile` then truncates and overwrites the shared inode, corrupting the external file despite the containment checks. The `readLink` check only catches symbolic links, not hard links. Consider checking the destination's link count (e.g. via `stat`) and refusing to write if it is greater than 1, or document that hard-link attacks are out of scope.

[macroscopeapp]

🟢 Lowchat/MarkdownMedia.tsx:37

mediaFileName only treats / as a path separator, so Windows-style sources like /C:\repo\clip.mp4 (produced by the Windows-drive-path escaping) return the full path C:\repo\clip.mp4 instead of just clip.mp4. When there is no nonempty alt text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both / and \ so Windows backslash separators are handled.

Suggested change

	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constbasename=withoutQuery.slice(withoutQuery.lastIndexOf("/")+1);
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}
	functionmediaFileName(src: string): string{
	constwithoutQuery=src.split(/[?#]/,1)[0]??src;
	constlastSep=Math.max(withoutQuery.lastIndexOf("/"),withoutQuery.lastIndexOf("\\"));
	constbasename=lastSep>=0 ? withoutQuery.slice(lastSep+1) : withoutQuery;
	returnbasename.length>0 ? safeDecode(basename) : safeDecode(withoutQuery);
	}

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MarkdownMedia.tsx around lines 37-41:
`mediaFileName` only treats `/` as a path separator, so Windows-style sources like `/C:\repo\clip.mp4` (produced by the Windows-drive-path escaping) return the full path `C:\repo\clip.mp4` instead of just `clip.mp4`. When there is no nonempty `alt` text, this full path becomes the media name shown in the UI and used for accessibility labels. Consider splitting on both `/` and `\` so Windows backslash separators are handled.

[macroscopeapp]

🟡 Mediumchat/MessagesTimeline.tsx:1966

Each thumbnail calls onImageExpand with images containing only its own loadedUrl, so the expanded viewer cannot navigate to other images in the same gallery. The images array should include all loaded thumbnails and index should point to the clicked one, so the preview can show the full gallery as expected.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/MessagesTimeline.tsx around line 1966:
Each thumbnail calls `onImageExpand` with `images` containing only its own `loadedUrl`, so the expanded viewer cannot navigate to other images in the same gallery. The `images` array should include all loaded thumbnails and `index` should point to the clicked one, so the preview can show the full gallery as expected.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[cursor]

Command projection drops image paths

Medium Severity

For image_view activities, projectActivityPayload sets data.item from projectCommandData(data) ?? projectImageViewData(data). When the tool item includes any pruned command field (command, input.command, or result.command), command projection wins and image-view projection is skipped, so type, path, and savedPath never reach thread snapshots. Clients then derive no imagePath, so inline galleries and thread-image asset requests for those activities fail even though the full payload in persistence still carries the image path.

^{Reviewed by Cursor Bugbot for commit 58f9832. Configure here.}

[juliusmarminge]

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.