feat(canvas): build and securely deliver cloud artifacts

[k11kirky]

Problem

Canvases relied on the desktop file-system abstraction for source, versions, channels, and task filing. The paired backend remodel in #73874 replaces that surface with first-class canvas and channel APIs, so the desktop client must move to the new contract at the same time.

Ports PostHog/code#3835 into products/desktop/ after the monorepo migration.

Changes

• Move canvases onto typed canvas records, server-side source versions, publish/build records, and signed artifacts.
• Use the backend channel UUID consistently for Spaces navigation, stars, context, feeds, and task filing.
• Make build progress, failures, diagnostics, artifact refresh, undo, and revert observable in the canvas UI.
• Restrict built artifact frames to their configured artifact origin and revoke their data bridge after navigation.
• Remove the retired desktop file-system and local canvas-preview paths.
• Preserve the imported Spaces dialog behavior while reconciling the port with the singular task repository contract.
• Require the artifact hostname ingress to forward only /canvas-artifacts/; infrastructure configuration handles this deployment boundary.

How did you test this code?

• pnpm install --frozen-lockfile --lockfile-only
• pnpm typecheck
• pnpm --filter @posthog/core test – 2,996 tests passed
• pnpm --filter @posthog/ui test – 2,528 tests passed
• pnpm --filter @posthog/shared test – 780 tests passed
• node scripts/check-host-boundaries.mjs – no new violations
• Biome check on the monorepo reconciliation files
• pnpm exec vitest run src/features/canvas/freeform/BuiltCanvas.test.tsx – 3 tests passed
• pnpm --filter @posthog/ui typecheck
• Biome check on BuiltCanvas.tsx and its test

I did not run a manual end-to-end generate → build → artifact flow.

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

Docs update

No documentation change. This ports an existing client implementation into the imported desktop tree.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Codex applied the /porting-code-prs skill to preserve the source patch series and authorship, map it under products/desktop/, retain the monorepo lockfile security overrides, and reconcile conflicts against the imported Spaces tree. The original 27 commits were republished as GitHub-verified commits, followed by verified migration-reconciliation and artifact-isolation commits.

---

Created with PostHog Code

[trunk-io]

😎 Merged successfully - details.

[github-actions]

Hey @k11kirky! 👋

It looks like your git author email on this PR isn't your @posthog.com address (k11kirky@gmail.com). Since you're on the PostHog team, it's worth pointing your local git author email at your @posthog.com address. Why it matters:

• Consistent work identity in git history — internal tooling that attributes commits to team members keys off your @posthog.com address.
• Keeps team contributions easy to tell apart from external community ones when scanning history.

You can fix it for this repo with:

git config user.email "you@posthog.com"

Or set it globally with git config --global user.email "you@posthog.com". No need to redo this PR — just a nudge for next time. 🙂

[greptile-apps]

Too many files changed for review. (131 files found, 100 file limit)

Bypass the limit by tagging @greptile-apps to review.

[trunk-io]

   

View Full Report ↗︎ ⋅ Docs

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

Fixed/addressed: 1 · PR risk: 0/10

[k11kirky]

Required CI is green. The remaining review finding concerns the published artifact capability/permission boundary. I am not changing security-sensitive permission enforcement during this automated CI-feedback turn based on review guidance alone; this needs explicit human review and direction.

[Piccirello]

Agent-driven security review — findings inline.

[Piccirello]

Medium · authz · confidence 5/5

Capability enforcement is switched off by a local UI toggle any viewer can click.

interactive comes from useIsDashboardEditing(dashboardId), which reads dashboardEditStore — a plain Zustand store holding editing: Record<string, boolean>. It's flipped by the "Edit" button in components/WebsiteLayout.tsx, and FreeformEditControls renders that button unconditionally: no authorship check, no access-control check, no server involvement.

The published manifest's capabilities are presented as a security control across both halves of this work. The server's CanvasSourceProjectSerializer help text says "the host enforces these at runtime and validation rejects undeclared ph calls", and validate_source_project blocks a publish whose code calls undeclared ph.*. This line is that runtime enforcement, and it's one click from off for any viewer on any canvas.

Impact — user B opens a canvas that user A's agent published, clicks Edit (a normal, always-visible affordance), and A's canvas gets ungated ph.query (arbitrary HogQL), ph.loadInsight (any short id), and ph.capture (any event name), all executed with B's credentials against B's project. Canvas source is agent-authored, so a prompt-injected generation is the realistic way a canvas comes to want more than it declared. Egress stays capped by the artifact CSP and the posthog.com-only openExternal allowlist, so this is undeclared data access and event writes rather than exfiltration.

Fix — derive the ungated path from something authoritative (authorship, or project write access on the canvas) rather than from a client-side view-mode toggle. If the toggle is meant to stay the trigger, the gate has to move somewhere the canvas's viewer can't flip.

_{Agent-driven security review.}

[Piccirello]

Low · authz · confidence 5/5

assertCanvasCapability is an allowlist of rejections rather than a default-deny, so it fails open in two directions.

1. if (!capabilities) return; — no manifest means every method is allowed.
2. Any method outside {query, loadInsight, capture} passes unchecked, because the function is a sequence of per-method rejections with no terminal throw.

(2) is already primed to matter: canvasToHostMessageSchema accepts method: "run" (core/src/canvas/freeformSchemas.ts), and the comments there and in freeformDataBridge.ts say Phase 3 makes run the view-mode data path — the one that most needs gating. Today run throws "not available yet" in handleFreeformDataRequest, so there's no live hole; the shape is the defect.

On (1), the docstring justifies fail-open as covering the window where "the manifest hasn't loaded yet". That window doesn't exist on this path: capabilities and artifactUrl are both read off the same publishedBuild in the same render (FreeformCanvasView.tsx → usePinnedArtifact), so a rendered artifact always has its manifest. The remaining routes to undefined are the interactive toggle (separate comment) and the pinned artifact outliving publishedBuild when lifecycle goes undefined — worth checking whether a canvas→canvas route change remounts FreeformCanvasView, since WebsiteDashboard.tsx puts no key on it.

Fix — switch on the method and throw for anything unrecognized, and make "ungated" an explicit value (a sentinel or a separate prop) so a missing manifest can't be spelled the same way as a deliberate bypass:

export function assertCanvasCapability(
  capabilities: CanvasCapabilities | "ungated",
  method: string,
  payload: unknown,
): void {
  if (capabilities === "ungated") return;
  switch (method) {
    case "query": ...
    case "loadInsight": ...
    case "capture": ...
    default:
      throw new Error(`Method "${method}" is not allowed by this canvas`);
  }
}

_{Agent-driven security review.}

[Piccirello]

Low · availability · confidence 3/5

The focus gate on open-external doesn't hold — canvas code can satisfy it without any user interaction.

document.activeElement === iframeRef.current is checked against the host document. Canvas code can call .focus() on an element inside the artifact frame at load; focus moving into a nested browsing context makes the containing iframe the ancestor document's activeElement. So the guarantee stated in canvasHostMessageRouter.ts — "a real link click moves focus into the iframe; requiring it stops canvas code from auto-opening URLs on load" — isn't one. The window.confirm below is what actually holds.

Impact — a canvas can drive a modal confirm dialog at the throttle rate (1/s) from the moment it loads, which blocks the desktop window. The isSafePostHogUrl allowlist caps everything beyond the nuisance, so this is availability rather than exfiltration.

Fix — key the gate on a real user-activation signal (a recent trusted pointer or key event on the host) instead of activeElement. If the focus check stays as-is, drop the guarantee from its doc comment so the next reader doesn't treat it as the gate.

_{Agent-driven security review. 3/5: the activeElement behaviour is standard but I didn't run it, and whether the dialog spam sustains depends on the artifact frame being site-isolated into its own process, which isn't visible from the repo.}

[k11kirky]

/trunk merge

[adamleithp]

/trunk merge

[github-actions]

Could not verify team-posthog-code membership (GitHub API error). Auto-release is limited to members of the team-posthog-code GitHub team, so this will ship with the next scheduled release instead.

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-08-03 23:54 UTC	Run
prod-us	✅ Deployed	2026-08-04 00:08 UTC	Run
prod-eu	✅ Deployed	2026-08-04 00:10 UTC	Run