[Bug]: 401 Unauthorized on all browser API calls when running via Docker Compose

[amrilsyaifa]

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?

Issue

When running Open Design via docker compose up -d, the browser UI loads correctly
but every API call (e.g. /api/version, /api/runs) returns 401 API_TOKEN_REQUIRED,
making the app completely unusable.

Secondary issue: docker compose build fails

scripts/postinstall.mjs includes apps/daemon in its build targets and runs
during pnpm install. At that point in the Dockerfile, only
apps/daemon/package.json has been copied — tsconfig.json and src/ are not
yet present — so tsc -p tsconfig.json fails with:

error TS5058: The specified path does not exist: 'tsconfig.json'.
Fix: Skip build targets whose tsconfig.json is absent (the Dockerfile's
explicit pnpm --filter @open-design/daemon build step after COPY apps handles
the daemon build correctly).

Environment
Docker Desktop (macOS / Windows / Linux)
docker.io/vanjayak/open-design:latest pre-built image or local build
Any browser on the Docker host

Steps to reproduce

Steps to reproduce

1. Follow the Docker quickstart in deploy/README.md
2. Set OD_API_TOKEN in deploy/.env
3. docker compose up -d
4. Open http://localhost:7456 in a browser
5. Open DevTools → Network tab

Result: Every /api/* request returns:

{
  "error": {
    "code": "API_TOKEN_REQUIRED",
    "message": "Authorization: Bearer <OD_API_TOKEN> required"
  }
}

Expected behavior

Expected behavior
The browser UI should work without manually sending a Bearer token —
same as the local dev (pnpm tools-dev) experience.

Open Design version

0.8.1

Platform

macOS (Apple Silicon)

Logs (optional)

Screenshots (optional)

Issue

Screen.Recording.2026-06-09.at.22.14.08.mov

Expected

Screen.Recording.2026-06-09.at.22.16.47.mov

Additional context

Root cause
Docker NAT. When Docker forwards 127.0.0.1:7456 (host) → container port 7456,
the daemon sees the TCP peer address as the Docker bridge gateway (e.g. 172.17.0.1),
not 127.0.0.1.

The auth middleware in apps/daemon/src/server.ts bypasses the Bearer check for
loopback peer addresses:

if (isLoopbackPeerAddress(req.socket?.remoteAddress)) return next();
isLoopbackPeerAddress('172.17.0.1') returns false, so the bypass never fires.
The web frontend never sends a Bearer token (it has always relied on this bypass),
so every API call returns 401.

Affected request headers (from browser DevTools)

host: 127.0.0.1:7456
sec-fetch-site: same-origin
// no origin header
// no authorization header
Fix
Add isLoopbackBrowserRequest() as a fallback — checks the HTTP Host and
Origin headers instead of the TCP peer address. Both headers are browser-set
and survive Docker NAT intact.

function isLoopbackBrowserRequest(req): boolean {
  const hostname = (req.get('host') ?? '').replace(/:\d+$/, '');
  if (!isLoopbackHostname(hostname)) return false;
  const origin = req.get('origin');
  if (!origin) return true;
  try { return isLoopbackHostname(new URL(origin).hostname); }
  catch { return false; }
}

Auth middleware bypass updated to:

if (isLoopbackPeerAddress(req.socket?.remoteAddress) || isLoopbackBrowserRequest(req)) return next();

Security: Origin must also be loopback when present — blocks DNS-rebinding attacks
and prevents OD_ALLOWED_ORIGINS reverse-proxy deployments from accidentally
bypassing Bearer auth.

[open-design-bot]

🎉 ✨ Welcome to Open Design, @amrilsyaifa!

✨ 🔥 Lit the spark.

🌱 Every 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（中文）

[maxmilian]

/claim

I'd like to take the secondary bug (docker compose build failing with TS5058). Root cause verified against main:

• deploy/Dockerfile runs pnpm install --frozen-lockfile at a stage where only apps/daemon/package.json has been copied (no tsconfig.json / src/ yet)
• the root postinstall (scripts/postinstall.mjs) unconditionally builds every target in buildTargets, including apps/daemon
• so tsc -p tsconfig.json fails with TS5058 and the whole image build aborts

This regressed when apps/daemon was added to buildTargets — the docker-image workflow only fires on version tags (last run 2026-05-16), so CI never exercised the Dockerfile since.

Plan: skip build targets whose sources aren't present (as suggested in the report), which is a no-op for normal installs. I'll send a PR referencing this issue for the build failure only — the primary 401 API_TOKEN_REQUIRED behavior touches daemon auth design, so leaving that part to maintainers.

[lefarcen]

Hey @maxmilian! 🙌 That's a tight root-cause write-up — the / frozen-lockfile timing is exactly the right framing, and scoping to just the TS5058 build failure keeps the PR clean.

You're all set — assigned and claimed. Roughly how long do you think this'll take? (a few hours / 1–3 days / ~1 week / longer) — just helps us time check-ins sensibly.

[lefarcen]

PR #4039 is now open to address the secondary build failure from this issue.

Root cause (confirmed on main): scripts/postinstall.mjs unconditionally runs tsc -p tsconfig.json for every build target, including apps/daemon. The Dockerfile's multi-stage layout copies only apps/daemon/package.json before running pnpm install, so tsconfig.json and src/ aren't present yet — causing the TS5058 abort.

The fix adds a single existsSync guard to skip build targets whose tsconfig.json is absent from the install context; a companion test enforces the invariant that every target ships a checked-in tsconfig.json for full checkouts. The primary 401 API_TOKEN_REQUIRED auth issue remains open and separate.

[lefarcen]

Hey @maxmilian — that split still looks exactly right from here. Keeping PR #4039 focused on the TS5058 Docker build regression while leaving the 401 API_TOKEN_REQUIRED path open avoids mixing a straightforward install-context fix with a daemon auth boundary change.

Thanks for scoping it that way and for grounding the regression to the postinstall build-target change on main. We'll keep this issue open for the browser-auth side until that part has its own fix.

[lefarcen]

Hey @maxmilian — PR #4039 has been quiet for about a day. Anything you want feedback on, or are you just mid-iteration?