fix(desktop): let dev canvas artifacts load past local network access checks - #83057
Conversation
… checks Chromium blocks the sandboxed canvas iframe's navigation to the localhost artifact origin because the frame's opaque origin counts as public and the permission cannot be granted. Dev-only switch; production artifact origins are public and unaffected. Generated-By: PostHog Desktop Task-Id: 1df9582a-9666-4504-9721-0fcd1ada0554
|
😎 Merged successfully - details. |
|
Hey @k11kirky! 👋 It looks like your git author email on this PR isn't your
You can fix it for this repo with: git config user.email "you@posthog.com"Or set it globally with |
|
React Doctor found no issues in the changed files. 🎉 Reviewed by React Doctor for commit |
HostHog preview —
|
|
/trunk merge |
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| // as public, so the artifact navigation is blocked with no way to grant the | ||
| // permission. Production artifact origins are public and unaffected. | ||
| if (isDev) { | ||
| app.commandLine.appendSwitch("disable-features", "LocalNetworkAccessChecks"); |
There was a problem hiding this comment.
When a configured third-party MCP app executes script in its sandboxed opaque-origin iframe during an unpackaged desktop session, this process-wide switch also disables Local Network Access enforcement for that content, allowing it to probe or interact with localhost and private-network services that Chromium would otherwise block.
How this was verified: The MCP app iframe path was traced through its script-enabled opaque-origin sandbox into the same Electron session affected by this process-wide switch, without the artifact preview's network lockdown.
Knowledge Base Used: Desktop App and Agent Framework
Prompt To Fix With AI
This is a comment left during a code review.
Path: products/desktop/apps/code/src/main/bootstrap.ts
Line: 97
Comment:
**Process-wide local network bypass**
When a configured third-party MCP app executes script in its sandboxed opaque-origin iframe during an unpackaged desktop session, this process-wide switch also disables Local Network Access enforcement for that content, allowing it to probe or interact with localhost and private-network services that Chromium would otherwise block.
**How this was verified:** The MCP app iframe path was traced through its script-enabled opaque-origin sandbox into the same Electron session affected by this process-wide switch, without the artifact preview's network lockdown.
**Knowledge Base Used:** [Desktop App and Agent Framework](https://app.greptile.com/posthog-org-19734/-/custom-context/knowledge-base/posthog/posthog/-/docs/desktop-app.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
|
Note 🤖 stamphog reviewed Greptile raised a substantive, traced security concern (dev-only LNA bypass is process-wide, so third-party MCP iframes in the same Electron session also lose Local Network Access enforcement) and it remains unresolved and unaddressed despite one human approval; this is security-sensitive surface and needs that concern resolved before auto-approval.
Gate mechanics and policy version
|
2 participants
Problem
A published canvas in the local dev desktop app renders nothing: the artifact iframe fails with "Access to internal resource at 'http://localhost:8010/canvas-artifacts/…' from origin 'null' has been blocked by CORS policy".
Changes
How did you test this code?
Automatic notifications
Docs update
None.
🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Claude diagnosed the reported CORS error as a Chromium Local Network Access block on the sandboxed artifact iframe and added the dev-only feature switch. Skills invoked: posthog-desktop, writing-pr-descriptions.
Created with PostHog Desktop