Plugin iframe postMessage bridge: cli-invoke never reaches cli_run

[mayagore]

Summary

Building phosphene, a viewer plugin that calls agentCompletionsCreateAgentCompletion via new ObjectiveAI({ viewer: true }). The plugin renders in the viewer tab, but API calls hang — the cli-invoke postMessage from the iframe never triggers cli_run on the Rust side.

What works

• CLI → API → Claude works end-to-end. Tested directly:

  objectiveai api agent completions post --body-inline '{"agent":{"upstream":"claude_agent_sdk",...},...}'
  → {"type":"notification","value":{...,"content":"Hey!",...}}
  

• Plugin renders in the viewer via plugin:// scheme (single-file build with viteSingleFile() to avoid CORS issues with the sandboxed iframe's opaque origin)
• isViewerMode() returns true — window.parent !== window is correct
• Viewer compiled with --features cli — cli_run Tauri command is registered
• API server running on custom port with claude_agent_sdk enabled

What fails

The SDK's viewerApiCallUnary → viewerApiCallChunks → invokeCli(args) → window.parent.postMessage({ kind: "cli-invoke", args }, "*") fires from the iframe, but:

• No cli_run activity appears in the viewer's stdout
• No API requests reach the API server
• The async iterator from invokeCli() never yields — the promise hangs until our 15s timeout catches it

After timeout, the plugin falls back to mock data (which is why it still shows directions/scores).

Suspected cause

plugin-bridge.ts:onIframeMessage receives the postMessage and calls findPluginByWindow(event.source). This checks handle.iframe.contentWindow === event.source. Possible failure modes:

1. contentWindow of a plugin://-scheme sandboxed iframe (no allow-same-origin) might be null or inaccessible in WKWebView
2. registerIframe might not have been called by the time the first cli-invoke fires (race condition on tab mount)
3. The event.source identity check might not work across the custom URI scheme boundary in WKWebView

Environment

• macOS (aarch64), Tauri debug build via pnpm tauri dev -- --features cli
• @objectiveai/sdk v2.0.11
• Plugin manifest: viewer_zip (served via plugin:// scheme)
• Viewer binary compiled with --features cli (688 crates including objectiveai-cli)
• API server on port 5002 (port 5000 held by macOS ControlCenter)
• config.json: api.mode: "local", api.port: 5002, api.local.claude_agent_sdk: true

To reproduce

# 1. Clone phosphene, install, build
cd phosphene-viewer && pnpm install && pnpm build

# 2. Symlink plugin (or run install-dev.sh)
ln -sfn /path/to/phosphene/objectiveai.json ~/.objectiveai/plugins/phosphene.json
mkdir -p ~/.objectiveai/plugins/phosphene
ln -sfn /path/to/phosphene/phosphene-viewer/dist ~/.objectiveai/plugins/phosphene/viewer

# 3. Start API server
cd objectiveai-api && source .env && export CLAUDE_AGENT_SDK
PORT=5002 cargo run -p objectiveai-api --no-default-features

# 4. Start viewer
pnpm --filter objectiveai-viewer run tauri dev -- --features cli

# 5. Click phosphene tab → type intent → "generate directions"
# → HUD shows "bridge: direction generation: no response after 15s"

Question

Is there a known constraint or setup step for getting cli-invoke postMessages from a plugin://-scheme sandboxed iframe to reach onIframeMessage in the viewer host? Is findPluginByWindow expected to work with plugin:// custom scheme iframes in WKWebView?

[mayagore]

Root cause found

Dug deeper today — the issue isn't findPluginByWindow or contentWindow identity. The postMessage IS being sent, but the browser silently drops it because of a targetOrigin mismatch.

plugin-bridge.ts:67-72 — deriveTargetOrigin():

function deriveTargetOrigin(src: string): string {
  try {
    return new URL(src).origin;  // returns "plugin://localhost"
  } catch {
    return "*";
  }
}

PluginPane.tsx:25 — iframe sandbox:

sandbox="allow-scripts allow-forms"

No allow-same-origin → iframe origin is null (opaque). The bridge posts to "plugin://localhost" but the iframe's origin is null → browser blocks delivery. Console confirms:

Unable to post message to plugin://localhost. Recipient has origin null.
    plugin-bridge.ts:116

The iframe→parent direction works (SDK uses "*"), so invokeCli() fires successfully. But the response never comes back, so the async iterator hangs.

Introduced in 5ec23b520 (May 17) which tightened postMessage from "*" to derived targetOrigin — correct for http:// origins, but breaks plugin:// scheme + sandbox.

Narrowest fix

One line in deriveTargetOrigin():

function deriveTargetOrigin(src: string): string {
  try {
    const url = new URL(src);
    if (url.protocol === "plugin:") return "*";
    return url.origin;
  } catch {
    return "*";
  }
}

This preserves the security tightening for viewer_url (http/https) plugins while fixing plugin:// scheme iframes where the sandbox makes a specific targetOrigin impossible.

Alternative: add allow-same-origin to the sandbox — but that's a bigger security surface change.

[WiggidyW]

Fixed in a1490e6 — thanks for the excellent diagnosis, it was exactly right: the sandbox (allow-scripts allow-forms, no allow-same-origin) gives the iframe an opaque origin, so the targetOrigin derived since 5ec23b5 could never match and the browser silently dropped every host→iframe message.

What changed: deriveTargetOrigin() in objectiveai-viewer/src/plugin-bridge.ts now returns "*" unconditionally instead of new URL(src).origin.

Why broader than the suggested plugin:-only special case: PluginPane applies the same sandbox to all plugin iframes, including http(s) viewer_url plugins — their origin is just as opaque, so "https://..." targetOrigins were being dropped identically. Under this sandbox no concrete targetOrigin can ever deliver; the scheme isn't the variable. Security still holds: messages are posted directly to the registered iframe.contentWindow (never broadcast), and the iframe→host direction keeps its findPluginByWindow identity gate. We deliberately did not add allow-same-origin. If the sandbox ever gains it, the derived-origin tightening can be restored — the src plumbing is left in place for that.

Caveat: not yet verified end-to-end. The viewer currently doesn't compile due to an in-progress command refactoring, so I couldn't run the phosphene repro against this fix yet. Will verify once that refactoring lands; if you get a chance to try it against your setup before then, feedback welcome.