Fix browser runtime package delivery for local Playground evals

[chubes4]

Problem

Studio Web now reuses the existing visible WP Codebox Playground for generation instead of booting a second Playground scope. That exposed a WP Codebox browser runtime package delivery gap for local/headless evals.

When Studio Web prepares the single visible Codebox runtime with the coding component plugins (agents-api, data-machine, data-machine-code) and keeps package delivery as URLs, Playground attempts to fetch local package URLs as HTTPS and fails:

https://127.0.0.1:63498/wp-content/uploads/wp-codebox/browser-runtime-plugins/agents-api-3324427f6ee8470a.zip
net::ERR_SSL_PROTOCOL_ERROR

Console evidence:

Studio Web: failed to start WordPress preview BlueprintStepExecutionError: Error when executing the blueprint step #2: Could not download "http://127.0.0.1:63498/wp-content/uploads/wp-codebox/browser-runtime-plugins/agents-api-3324427f6ee8470a.zip".
Original error: TypeError: Failed to fetch

Switching the Studio Web filter back to data URLs for local hosts avoids the HTTPS localhost fetch issue, but reintroduces the oversized REST/session payload problem: /studio-web/v1/targets/preview-session returns 500 while embedding large component ZIP data URLs.

Why this belongs in WP Codebox

Studio Web should not manage component package transport. WP Codebox owns browser runtime dependency packaging and delivery. Studio Web should only request a visible Codebox runtime with the needed dependencies, then run generation in that same runtime.

Correct Studio Web flow:

existing visible WP Codebox Playground
  -> run browser Codebox recipe in that runtime
  -> write/import generated website bundle through SSI in that runtime
  -> switch/activate generated theme in that same runtime
  -> reload/navigate preview

No second Playground scope. No hidden generation runtime. No Studio Web transport workaround.

Evidence

Studio Web local evidence paths from the controller machine:

• URL-delivery failure evidence: /var/folders/lr/c_cmmt7s0592m4njz99v5yb40000gn/T/opencode/studio-web-live-eval-after-coding-runtime/evidence.json
• Browser console: /var/folders/lr/c_cmmt7s0592m4njz99v5yb40000gn/T/opencode/studio-web-live-eval-after-coding-runtime/live-2026-06-01T18-36-51-666Z/local-restaurant-launch/studio-web/wp-codebox-artifacts/runtime-mpvjvr0m-f7jao4/files/browser/console.jsonl
• Data-URL detour failure evidence: /var/folders/lr/c_cmmt7s0592m4njz99v5yb40000gn/T/opencode/studio-web-live-eval-after-local-data-url/evidence.json

Relevant console lines from URL-delivery failure:

Failed to load resource: net::ERR_SSL_PROTOCOL_ERROR
https://127.0.0.1:63498/wp-content/uploads/wp-codebox/browser-runtime-plugins/agents-api-3324427f6ee8470a.zip

Failed to load resource: net::ERR_SSL_PROTOCOL_ERROR
https://127.0.0.1:63498/wp-content/uploads/wp-codebox/browser-runtime-plugins/data-machine-5f1cbbb6db897ac1.zip

Failed to load resource: net::ERR_SSL_PROTOCOL_ERROR
https://127.0.0.1:63498/wp-content/uploads/wp-codebox/browser-runtime-plugins/data-machine-code-e0c6e98038882d01.zip

Acceptance criteria

• WP Codebox can deliver browser runtime component/plugin packages to Playground in local evals without relying on https://127.0.0.1 URLs.
• WP Codebox does not require embedding multi-megabyte component ZIP data URLs in Studio Web REST/session responses.
• Studio Web live eval can prepare one visible Codebox runtime with agents-api, data-machine, data-machine-code, ai-provider-for-openai, static-site-importer, and the Studio Web runtime pieces.
• Generation runs inside that same visible Playground and reaches the SSI import/theme activation path without booting a second Playground scope.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode (GPT-5.5)
• Used for: Diagnosing the Studio Web live eval failure and drafting this issue from observed browser/runtime evidence.

[chubes4]

Post-merge Studio Web eval still reproduces the package transport failure against merged WP Codebox main.

Tested with local override switched to at and Studio Web live eval:

Result: eval still failed at .

New browser evidence:

Console shows Playground still cannot fetch the local component package URL:

Evidence files:

So #412 moved the URL shape from to , but did not solve the underlying browser-safe local package delivery problem. Studio Web is still using a single visible Codebox runtime; this is still package transport.

[chubes4]

Post-merge Studio Web eval still reproduces the package transport failure against merged WP Codebox main.

Tested with local override switched to origin/main at 23575e1 and Studio Web live eval:

node scripts/website-generation-eval.mjs live --scenario local-restaurant-launch --adapter studio-web --wp-path /Users/chubes/Studio/intelligence-chubes4 --plugin-source wp-codebox=/Users/chubes/Developer/wp-codebox@fix-browser-runner-playground-detection/packages/wordpress-plugin --artifacts-dir /var/folders/lr/c_cmmt7s0592m4njz99v5yb40000gn/T/opencode/studio-web-live-eval-after-wp-codebox-412 --output /var/folders/lr/c_cmmt7s0592m4njz99v5yb40000gn/T/opencode/studio-web-live-eval-after-wp-codebox-412/evidence.json

Result: eval still failed at website_artifact_bundle_captured.

New browser evidence:

Failed to load resource: net::ERR_SSL_PROTOCOL_ERROR
https://localhost:60504/wp-content/uploads/wp-codebox/browser-runtime-plugins/agents-api-3324427f6ee8470a.zip

Failed to load resource: net::ERR_SSL_PROTOCOL_ERROR
https://localhost:60504/wp-content/uploads/wp-codebox/browser-runtime-plugins/data-machine-5f1cbbb6db897ac1.zip

Failed to load resource: net::ERR_SSL_PROTOCOL_ERROR
https://localhost:60504/wp-content/uploads/wp-codebox/browser-runtime-plugins/data-machine-code-e0c6e98038882d01.zip

Console shows Playground still cannot fetch the local component package URL:

Studio Web: failed to start WordPress preview BlueprintStepExecutionError: Error when executing the blueprint step #2: Could not download "http://localhost:60504/wp-content/uploads/wp-codebox/browser-runtime-plugins/agents-api-3324427f6ee8470a.zip".
Original error: TypeError: Failed to fetch

Evidence files:

• /var/folders/lr/c_cmmt7s0592m4njz99v5yb40000gn/T/opencode/studio-web-live-eval-after-wp-codebox-412/evidence.json
• /var/folders/lr/c_cmmt7s0592m4njz99v5yb40000gn/T/opencode/studio-web-live-eval-after-wp-codebox-412/live-2026-06-01T18-55-24-642Z/local-restaurant-launch/studio-web/wp-codebox-artifacts/runtime-mpvkjllf-sd6v5z/files/browser/console.jsonl

So PR #412 moved the URL shape from 127.0.0.1 to localhost, but did not solve the underlying browser-safe local package delivery problem. Studio Web is still using a single visible Codebox runtime; this is still package transport.

[chubes4]

Post-PR #414 verification still fails in the Studio Web live eval.

Tested WP Codebox at using the same Studio Web single-visible-Codebox eval:

Result: , failing phase .

This is no longer only the previous browser HTTPS fetch path. The new local package installer step is running, but the Playground-side PHP fetch still cannot read the local package URL:

Network still shows a related failed browser request:

Evidence files:

So #414 improved the shape, but the acceptance criteria is still unmet: Studio Web cannot yet prepare the single visible Codebox runtime with local component packages and proceed to browser generation.

[chubes4]

Post-PR #414 verification still fails in the Studio Web live eval.

Tested WP Codebox origin/main at afd8f0a using the same Studio Web single-visible-Codebox eval:

node scripts/website-generation-eval.mjs live --scenario local-restaurant-launch --adapter studio-web --wp-path /Users/chubes/Studio/intelligence-chubes4 --plugin-source wp-codebox=/Users/chubes/Developer/wp-codebox@fix-browser-runner-playground-detection/packages/wordpress-plugin --artifacts-dir /var/folders/lr/c_cmmt7s0592m4njz99v5yb40000gn/T/opencode/studio-web-live-eval-after-wp-codebox-414 --output /var/folders/lr/c_cmmt7s0592m4njz99v5yb40000gn/T/opencode/studio-web-live-eval-after-wp-codebox-414/evidence.json

Result: status: failed, failing phase website_artifact_bundle_captured.

This is no longer only the previous browser HTTPS fetch path. The new local package installer step is running, but the Playground-side PHP fetch still cannot read the local package URL:

PHP.run() failed with exit code 255
Warning: file_get_contents(http://localhost:56137/wp-content/uploads/wp-codebox/browser-runtime-plugins/agents-api-3324427f6ee8470a.zip): Failed to open stream: HTTP request failed! HTTP/1.1 400
Fatal error: Uncaught RuntimeException: Could not read browser plugin package. in /internal/eval.php:11

Network still shows a related failed browser request:

https://localhost:56137/wp-content/uploads/wp-codebox/browser-runtime-plugins/agents-api-3324427f6ee8470a.zip
net::ERR_SSL_PROTOCOL_ERROR

Evidence files:

• /var/folders/lr/c_cmmt7s0592m4njz99v5yb40000gn/T/opencode/studio-web-live-eval-after-wp-codebox-414/evidence.json
• /var/folders/lr/c_cmmt7s0592m4njz99v5yb40000gn/T/opencode/studio-web-live-eval-after-wp-codebox-414/live-2026-06-01T19-09-40-927Z/local-restaurant-launch/studio-web/wp-codebox-artifacts/runtime-mpvl1ydq-xgso6t/files/browser/console.jsonl

So #414 improved the shape, but the acceptance criteria is still unmet: Studio Web cannot yet prepare the single visible Codebox runtime with local component packages and proceed to browser generation.