fix(pull-requests): render private GitHub images in PR bodies

[Xanacas]

Images embedded in pull request bodies rendered as broken placeholders: GitHub serves github.com/user-attachments/assets/… uploads only to an authenticated viewer, and the browser sends no GitHub cookies from the app's origin (verified: unauthenticated fetch → 404, with a gh token → 200).

Fixed by routing those URLs through the existing signed asset flow. The markdown image classifier in client-runtime returns a new GitHubAttachment source, clients request a signed /api/assets URL for it over the authenticated WebSocket, and the server resolves GitHub's redirect with the gh CLI token (cached, single-flight) and answers 302 to the short-lived signed storage URL. Image bytes flow from storage straight to the browser; the token never leaves the server. Claim expiry is bucketed so repeat issuances stay byte-identical and browser caches hit. Web and mobile both render through the shared classifier; public-repo uploads resolve anonymously if gh is not authenticated.

Verified end to end in a local web run against a private-repo PR — before/after screenshots in this comment.

Changes made by Claude Fable 5 (Claude Code).

🤖 Generated with Claude Code

Note

Render private GitHub attachment images in PR bodies via signed proxy URLs

• Adds shared isGitHubUserAttachmentUrl allowlist predicate and a github-attachment variant to AssetResource so recognized github.com/user-attachments URLs can be classified and proxied
• AssetAccess.issueAssetUrl now issues signed proxy URLs for GitHub attachments; resolveAsset validates the claim and returns a remote asset result; the GET asset route issues a 302 redirect to a resolved HTTPS storage location
• Introduces GitHubAttachmentProxy service that resolves a redirect location using a cached (5-min) GitHub CLI token, manual redirect handling, HTTPS-only filtering, and failure-to-null conversion; wired into the production server layer and assetsCreateUrl WebSocket RPC
• Web (ChatMarkdown) and mobile (ThreadFeed) markdown renderers route recognized GitHub attachment images through signed asset URLs; markdown without an environment ID still uses the direct GitHub URL
• Risk: resolveAsset returns null for expired, tampered, or no-longer-valid claims, and the asset route returns 404 when GitHubAttachmentProxy is unavailable or cannot resolve a location — callers that expect a file response for these assets must handle the new remote/redirect path

^{Macroscope summarized 9a5a1de.}

[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: faf14ea4-c819-4b05-8b99-be736ecc7ffc

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

---

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

[macroscopeapp]

Effect Service Conventions: one finding — the new GitHubAttachmentProxy service adds backend behavior with no focused test. Service definition order, make/layer exports, Foo["Service"] typing, environment-based dependency acquisition, and the new Schema.TaggedErrorClass all match the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1da4829ea2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This change adds a server-side GitHub credential proxy and changes existing PR-image loading across web and mobile. Signed asset capabilities are minted from URL shape alone while the proxy can access private attachments through the environment credential, making authorization scope and cross-repository exposure important risks to examine.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[Xanacas]

Before/after from an integrated web pass against a private-repo PR (Vantisgo, PR body with three user-attachments screenshots):

Before (images 404 as broken placeholders):

After (rendered through the signed asset proxy; all three images load with real dimensions):

The integrated pass also caught a layer-wiring bug the unit tests could not see: route handlers resolve services at serve time, so the proxy layer had to be provided on the server runtime context rather than on makeRoutesLayer (fixed in 1a12535).

[macroscopeapp]

Reviewed the web-scoped changes (ChatMarkdown.tsx, pullRequest/pullRequestMarkdown.logic.ts) for shared-primitive use, Tailwind/CSS ownership, and environment routing.

Environment routing is correct: ChatMarkdownAssetImage requires an explicit environmentId, ChatMarkdown resolves it from threadRef?.environmentId ?? explicitEnvironmentId ?? null with no active-environment fallback, and every PullRequestMarkdown / PullRequestMarkdownEditor call site threads the owning environment explicitly.

One consistency finding on the new no-environment GitHub attachment branch (inline).

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

🔴 Critical assets/AssetAccess.ts:303

issueAssetUrl lets any authenticated WebSocket caller mint a capability for any syntactically matching private GitHub attachment URL, exposing attachments accessible to the server's gh credential across private repositories. Validating only isGitHubUserAttachmentUrl(url) does not establish repository or pull-request access; authorize the URL against the requesting session before issuing the capability.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/assets/AssetAccess.ts around line 303:

`issueAssetUrl` lets any authenticated WebSocket caller mint a capability for any syntactically matching private GitHub attachment URL, exposing attachments accessible to the server's `gh` credential across private repositories. Validating only `isGitHubUserAttachmentUrl(url)` does not establish repository or pull-request access; authorize the URL against the requesting session before issuing the capability.

[Xanacas]

This matches T3 Code's trust model on purpose, so no per-URL authorization is added:

• An authenticated WS session already holds this authority. Every paired client is the operator of this environment and can run arbitrary agents and shell commands on the host machine — including gh auth token or gh api against any repo the credential reaches. The asset capability grants nothing the session couldn't already do in one turn; there is no finer-grained principal inside a single environment to authorize against.
• The signed token is a transport shim, not a permission tier. Browsers can't attach the WS session's auth to <img> fetches, so the WS layer (already authenticated) mints a short-lived signed URL the image tag can use. It deliberately mirrors the existing attachment/workspace-file kinds, which likewise let any authenticated caller read any path the server can.
• The guards that do matter are in place: strict allowlist (github.com/user-attachments/assets/<id> only), the gh token never leaves the server, only an https redirect Location is returned, and tokens expire quickly.

Per the repo's guidance, security should not be over-indexed for operator-level features; adding PR-scoped URL authorization here would add real complexity without a boundary to protect.

[macroscopeapp]

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

[macroscopeapp]

One finding on the new GitHub-attachment image branches in apps/web/src/components/ChatMarkdown.tsx: the author's intrinsic width/height (and align) attributes that the Direct branch still forwards are now dropped for these images.

^{Posted via Macroscope — UI Consistency}

[Xanacas]

Superseded by a clean squash of the same change onto current main, with the client fallback chain and extra tests removed. See the new PR linked from this repository's PR list (fix(pull-requests): render private GitHub images in PR bodies).

[Xanacas]

Superseded by #9404.