[birme]

Summary

• src/api/api.ts read VITE_BACKEND_API_KEY via import.meta.env and sent it as an Authorization: Bearer header on every management request. All VITE_* vars are public by design (Vite inlines them into the browser bundle at build time), so any bundle built with the var set leaked the manager API key to anyone with DevTools (Security: VITE_BACKEND_API_KEY exposes API key in browser bundle #625, High severity).
• Removed the API_KEY constant and all Authorization: Bearer headers. Requests now authenticate via the OSC platform session: the browser talks to the manager same-origin and the short-lived *.sat session cookie (kept fresh by the existing /reauth flow) is sent automatically. fetch defaults to credentials: "same-origin", so no extra client config is needed.
• This is safe for production: the production Docker build never sets VITE_BACKEND_API_KEY (only MANAGER_URL/AUTH are baked in), so deployed bundles already send no Authorization header and rely on the session cookie today — this change only removes the dead-but-dangerous code path.
• Updated the README: removed the VITE_BACKEND_API_KEY=<service-access-token> npm run dev instructions and added a security note explaining the frontend must never hold the key. (.env.local.sample never referenced the var, so no change was needed there.)

Test plan

• npm test — 346 tests across 42 files pass
• npm run typecheck — clean
• npm run lint — clean (max-warnings 0)
• Verified no VITE_BACKEND_API_KEY / API_KEY / Authorization references remain in src/
• Confirmed no test asserted on the Authorization header (none did)
• Rotate any previously-exposed manager API keys out-of-band (operational follow-up, not code)

Closes #625

🤖 Generated with Claude Code

[birme]

Code Review — Verdict: LGTM

Automated self-review by today's daily-backlog-pr run (code-reviewer agent, a separate invocation from the implementer). Recorded as a marker comment because GitHub blocks state-bearing self-approval on a self-authored PR.

Summary: Clean, correct fix for the High-severity secret-exposure issue (#625). The manager API key is fully removed from the client — not merely relocated — and auth now relies on the OSC platform's same-origin session cookie, the mechanism the production deployment already used.

Blocking

None. Verified: zero reads of import.meta.env.VITE_BACKEND_API_KEY remain in src/ (only explanatory comment + README note); the removed Authorization header was already optional so same-origin production is unaffected; getBackendUrl() defaults to window.location.origin and fetch defaults to same-origin credentials so the *.sat cookie is attached; the 401 → reauth circuit-breaker path is intact; JSON POST/PATCH calls retain Content-Type.

Warnings (non-blocking)

• Local-dev against a remote OSC instance (cross-origin, README's --disable-web-security flow) won't attach the cookie under default credentials: "same-origin" — a dev-workflow note or credentials: "include" guidance would help. Not a production bug.
• No regression/guard test ships with the fix; a Vitest assertion that API calls carry no Authorization header (or a CI check forbidding VITE_BACKEND_API_KEY) would prevent silent reintroduction.

Suggestions

• .env.local.sample already has no key entry (issue item satisfied). Confirm operational key rotation (Security: VITE_BACKEND_API_KEY exposes API key in browser bundle #625) was handled outside this diff.