[Bug]: installs from source and from install.sh are dysfunctional

[3p3r]

Before you submit

• I searched existing issues and confirmed this is not a duplicate.
• I replaced the example text with the real behavior, reproduction steps, expected result, and version from the app's About menu or od --version.

What happened?

"https://open-design.ai/install.sh" redirects to the homepage and is not a shell script anymore.
Installing from source with git and running with pnpm also is entirely dysfunctional. After clicking any of the design Systems or trying to send a prompt, the entire app breaks with "daemon is unreachable" error and browser console is spammed with CORS issues and 403s

Steps to reproduce

1. Either install via the install.sh or git clone from source on a clean machine
2. Attempt to actually use the product, choose any of the examples, you get: "Failed to apply <style>. Make sure the daemon is reachable."

Expected behavior

1. "install.sh" should not redirect to an HTML page
2. install from source should not face CORS and 403 issues

Open Design version

ecb1f3a

Platform

Linux

Logs (optional)

It also happens on Windows, as well as Linux.

Screenshots (optional)

Additional context

No response

[open-design-bot]

🎉 ✨ Welcome to Open Design, @3p3r!

✨ 🔥 Lit the spark.

🌱 Your first contribution adds energy to the project. Thanks for showing up and helping Open Design grow.

💛 Thanks for helping Open Design grow. Keep building in the open. 🚀

🔗 Share on X (English) · 分享到 X（中文）

[3p3r]

I can confirm the native version works flawlessly. It's just the shell installer and source installs that suffer from these errors.

[lefarcen]

Hey @3p3r — thanks, that narrows it down a lot.

I checked https://open-design.ai/install.sh from here and it is currently serving the landing-page HTML instead of a shell script, so that part is a real bug.

For the source path, the daemon is unreachable + CORS/403 combo matches the daemon's same-origin guard when the web app is started outside the supported pnpm tools-dev run web flow (or without the matching reverse-proxy/origin setup). Could you share the exact command you used on the source install side? That’ll tell us quickly whether this is a docs/install-path bug or a runtime regression in the source workflow.

[3p3r]

I do run it with pnpm tools-dev run web, no proxy is involved. Outside of git cloning, pnpm installing and using pnpm tools-dev run web I have no other modifications to the documentation's guidance on running it via source. I tried accessing the web UI both through 127.0.0.1 and localhost and they both fail similarly.

[lefarcen]

Hey @3p3r — that’s helpful, thank you. Given you’re using the documented pnpm tools-dev run web flow with no proxy, this now looks like a real source-workflow regression rather than a setup mistake.

I checked the source path here: the dev web app is supposed to proxy /api/* to the daemon, and tools-dev is also supposed to pass the web port through to the daemon’s same-origin guard. So the 403/CORS behavior you’re seeing should not happen in that flow.

Could you paste one concrete failing request from DevTools Network — the request URL plus the 403 response body/JSON — and, if available, the exact Web: / Daemon: URLs that pnpm tools-dev run web prints on startup? That should tell us quickly whether a specific route is bypassing the dev proxy or whether the origin allowlist is being computed wrong at runtime.

[3p3r]

I think it's just CORS and 403 is red-herring. On the right I have it run with pnpm tools-dev run web and on the left you can see Chrome choking on CORS. Firefox behaves the same.

[lefarcen]

Hey @3p3r — I don’t think those are two separate signals.

In this codepath, a same-origin rejection can show up in DevTools as a CORS failure because the daemon returns 403 Cross-origin requests are not allowed without an Access-Control-Allow-Origin header, so the browser surfaces the blocked response as CORS. In other words, the browser-side CORS error can still be the symptom of the server-side 403.

The screenshot is still useful though — it means we should focus on the exact request that is escaping the expected dev proxy path. Could you open the first failing request in Network and paste these four fields from it: Request URL, Request Method, Origin request header, and the response body (or response preview)? That should be enough to pin whether one route is calling the daemon directly instead of going through /api/*.

[3p3r]

Request URL: http://127.0.0.1:44310/api/plugins/example-innovation/apply
Request Method: POST
Origin: http://127.0.0.1:44310
Request Headers:

POST /api/plugins/example-innovation/apply HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9,fa;q=0.8
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 42
Content-Type: application/json
DNT: 1
Host: 127.0.0.1:44310
Origin: http://127.0.0.1:44310
Pragma: no-cache
Referer: http://127.0.0.1:44310/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: <masked>
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
x-od-analytics-client-type: web
x-od-analytics-device-id: 3ee3c842-c45a-4ec5-a47c-1699689c1292
x-od-analytics-locale: en
x-od-analytics-session-id: c447b15d-df2f-4cf7-a7fc-1e898072a1a3

[lefarcen]

Hey @3p3r — this is a useful narrowing point.

From the code, POST /api/plugins/:id/apply itself is just a pure resolver and does not have its own route-level cross-origin block. So if this exact request is ending in 403, the failure is happening before the plugin handler runs — most likely in the generic daemon origin guard / web→daemon proxy layer, not in the plugin-apply logic itself.

That makes the next missing detail very specific: could you paste the response body for this request (even if DevTools shows it under Preview/Response), plus the Daemon: URL that pnpm tools-dev run web printed when it started? With those two pieces we can tell whether the request reached the daemon with the wrong forwarded origin/host, or whether something else on that path is returning the 403.

[lefarcen]

Thanks for the detailed headers @3p3r — this narrows it down significantly.

From your headers, this is same-origin from the browser's perspective (Origin: http://127.0.0.1:44310 → Host: 127.0.0.1:44310, Sec-Fetch-Site: same-origin), so the browser isn't initiating a cross-origin request.

I checked the code path: /api/plugins/:id/apply itself doesn't return 403 — it only returns 404 (missing plugin), 422 (missing inputs), or 500. A 403 comes from the daemon's global /api origin guard before the plugin route even runs.

Hypothesis: When you run pnpm tools-dev run web, the daemon should be started with OD_WEB_PORT=44310 so it trusts that web origin. If the daemon was launched separately or the port trust is stale/missing, it'll reject Origin: http://127.0.0.1:44310 even though the browser sees same-origin.

Next step: Could you paste:

1. The response body for the failed request (the 403 message)
2. The daemon log around startup — specifically whether it says trusting web origin port 44310

That'll confirm whether this is a stale daemon or a different issue.

[3p3r]

Seems like this is just an AI talking so I am not going to provide further details. Ticket has clear direction on what's happening. The response body is just a generic CORS rejection body from Chrome. Daemon log is in the screenshot.

[lefarcen]

Fair call, @3p3r — you’ve already provided enough to make this actionable.

At this point the issue looks like two concrete bugs on our side:

• https://open-design.ai/install.sh is serving the landing page HTML instead of a shell script.
• In the documented pnpm tools-dev run web source flow, POST /api/plugins/:id/apply is getting rejected before the plugin handler runs, which points at the dev proxy / daemon origin-guard path rather than your local setup.

No more details needed from you for now. A human maintainer should take it from here and reproduce against the clean tools-dev run web path directly.