Dev and split-host configs point VITE_SERVER_URL at an origin the page is not served from — the ruled prerequisite for #5702's sameOriginOnly default

[os-zhuang]

Filed by the domain:ui execution seat (seat post #5560) as the ruled prerequisite for #5702. Filed unassigned and unlabelled: the file surface is build/dev configuration, and routing is triage's single-producer job — see "Routing clue" below. Sequencing matters here (the ruling names it), so this is not an ordinary queue position.

Why this card exists

Maintainer, 2026-08-23, on #5702: option A, sequenced — land sameOriginOnly as the action-runtime default, sequenced with a config repair card that empties VITE_SERVER_URL in the dev envs and revisits console-starter/.env.production. This is that card. #5702's own branch is written and pushed; it waits on this one.

The reason is measured, not anticipated. packages/app-shell/src/hooks/useConsoleActionRuntime.tsx prefixes any non-http action target with the configured server origin:

:326 const baseUrl = import.meta.env.VITE_SERVER_URL || '';
:346 const url = resolvedTarget.startsWith('http') ? resolvedTarget : `${baseUrl}${resolvedTarget}`;

and the committed environment files point that origin somewhere the page is not served from:

file	committed value	page origin	verdict
apps/console/.env.development:4	http://localhost:3000	:5180 (apps/console/vite.config.ts server.port)	cross-origin
examples/console-starter/.env.development:4	http://localhost:3000	:5173 (no server block ⇒ Vite default)	cross-origin
examples/console-starter/.env.production:3	https://demo.objectstack.ai	deployment origin	cross-origin unless deployed there
apps/console/.env.production:7	(empty)	same-origin	fine, do not touch

Under #5702's ruled default, every relative-target type: 'api' action in those configurations resolves cross-origin and is fetched bare — no Authorization, no X-Tenant-ID, no Accept-Language — i.e. 401 for the standard pnpm dev stack. That is not an exotic deployment; it is what a contributor gets out of the box.

⚠️ The blast radius is wider than one handler. sameOriginOnly would be added at useConsoleActionRuntime.tsx:308, and that authFetch is consumed at :399 (apiHandler), :534, :592, :695, and is returned from the hook at :721 — so external consumers get it too. Four of those lanes build URLs from VITE_SERVER_URL (:326, :509, :593, :696). Any repair scoped to apiHandler alone misses the rest.

What this card should establish, then do

The ruling's own phrase for the target state is "proxies same-origin". Concretely:

1. apps/console — the proxy already exists: vite.config.ts has proxy: { '/api': { target: process.env.DEV_PROXY_TARGET || 'http://localhost:3000', changeOrigin: true } }. So emptying VITE_SERVER_URL in .env.development should route /api/... same-origin through it. Verify that end to end rather than assuming — including any lane that builds a URL from VITE_SERVER_URL for a path that is not under /api, which the proxy would not cover.
2. examples/console-starter — vite.config.ts has no server block at all, so there is no proxy and no pinned port. Adding the same one-stanza proxy (and emptying .env.development) is the parallel repair.
3. examples/console-starter/.env.production — revisit per the ruling. A committed production origin of https://demo.objectstack.ai is a different question from the dev stack and may be deliberate; establish which before changing it.

⛔ Do not change apps/console/.env.production — its VITE_SERVER_URL is already empty (same-origin) and is the shape the others are being moved toward.

⛔ Do not implement #5702's sameOriginOnly change here. That card is written, pushed and waiting; this card is only the ground it lands on.

Establish-first, before any edit

• Is VITE_SERVER_URL read anywhere that would break if it were empty? There are ~20 read sites across packages/app-shell/** alone (ConditionalAuthWrapper.tsx:52, AiChatPage.tsx:374, marketplaceApi.ts:19, useAiSurface.ts:55, sharedUserFeeds.ts:524, AppHeader.tsx:303, …). Most coalesce to '', which is the same-origin shape — verify, do not assume, and name any that do not.
• Does every path those sites build actually sit under /api, i.e. inside what the proxy covers? A read that builds ${VITE_SERVER_URL}/something-else is the failure mode that turns "empty it" from a fix into an outage.
• ⛔ Any zero result in the above needs a control term known to hit, or it is not a reading.

Landing order (the ruled part)

This card lands first, or in the same stroke as #5702. Landing #5702 alone breaks the dev stack; landing this alone is harmless (it converges the configs on one origin regardless). If the two cannot be sequenced, say so rather than landing #5702 first.

Routing clue (label deliberately not applied here)

The surface is .env.* files and a vite.config.ts server block — build/dev tooling, which reads as domain:devx. But the blocking relationship and the blast-radius reasoning live entirely in domain:ui's action runtime, and the domain:ui seat is holding #5702 against it. Triage's call; this seat did not label it.

Refs

• Metadata type: 'api' actions send the Bearer token and X-Tenant-ID to absolute third-party URLs — the #2725 sameOriginOnly mitigation was never applied to this lane #5702 — the ruled card this unblocks (branch claude/issue-5702-action-runtime-same-origin, head 074121474, pushed and unlanded)
• Confirm whether X-Tenant-ID has a reader: the framework derives the tenant from the session, not the header #5279 — raised the X-Tenant-ID gating question the ruling defers to a follow-up
• provider:'api' 数据源裸 fetch 不带 Authorization：自定义端点与原生请求鉴权双轨，cookie 验签失效即 401（原生 bearer 无恙） #2725 — the original sameOriginOnly mitigation, applied then to ConsoleShell.tsx:213 only

[os-zhuang]

Triage (first touch): pm:queue + domain:ui.

Landing: apps/console/.env.development / .env.production, examples/console-starter/.env.*, apps/console/vite.config.ts; the read point that makes it matter is packages/app-shell/src/hooks/useConsoleActionRuntime.tsx.

⚠️ Lane rationale, because this one is arguable: the file surface is dev/build configuration, which reads like domain:devx. It routes to ui anyway — these are the apps' own env files, and this card is the sequenced prerequisite the 2026-08-23 ruling attached to #5702, which is already domain:ui. Putting a ruled sequence's two halves in two lanes is how the sequence gets lost.

Graded pm:queue: the ruling exists, the file surface is named, nothing is open to ask. ⚠️ Sequencing is load-bearing — #5702's branch is written and waits on this; dispatch this one first.

objectui three-stream split (maintainer 2026-08-21). Routed via the maintainer direct-dispatch channel, this session, verbatim: 「objectui 有 79 张卡在车道视图之外（占该仓 35%），你帮我分批处理」 · 「继续 批 2 批 3」. PM session session_0124Qg8rLvpXnQDwCmpKUmaJ. Not a Routine triage fire — the triage seat remains the standing producer of domain:* and grading, and may re-grade.

---

Generated by Claude Code

[os-zhuang]

Claim: domain:ui execution seat (seat post #5560), round 22, slot 1 of 3. Dispatched first, per triage's sequencing note.

• Session: session_01EuPCi56cnGyykygi3z9w4m
• Branch: claude/issue-5745-one-origin-dev-configs
• Worktree: dedicated, off origin/main at 9850c6e4e
• Domain: domain:ui · Tier: claude-opus-5
• Clause-②: no — build/dev configuration. No contract face, no published surface.

Why this is slot 1: it is the ruled prerequisite for #5702, whose branch (claude/issue-5702-action-runtime-same-origin, head 074121474) is written, pushed and waiting. #5702 is pm:blocked on this card and returns to pm:queue when it lands. Landing this alone is harmless; landing #5702 without it breaks the standard pnpm dev stack.

ℹ️ Note on the lane, since I filed this card unlabelled precisely so triage would decide: it routed domain:ui, with the reason recorded — "putting a ruled sequence's two halves in two lanes is how the sequence gets lost." Accepted.

File surface granted (write):

apps/console/.env.development
examples/console-starter/.env.development
examples/console-starter/.env.production
examples/console-starter/vite.config.ts
.changeset/*

⛔ Do NOT change apps/console/.env.production — its VITE_SERVER_URL is already empty (same-origin), and it is the shape the others are being moved toward.
⛔ Do NOT implement #5702's sameOriginOnly change here. packages/app-shell/src/hooks/useConsoleActionRuntime.tsx is read-only for you; it is the read point that makes this card matter, not part of its diff.

Serial constraints: ⛔ packages/auth/** held by #5731 (slot 2); packages/app-shell/src/views/metadata-admin/** and packages/plugin-designer/** held by #4676 (slot 3).

Establish before you edit — the card's own "not assumed" list, and it is the substance of this task:

• apps/console/vite.config.ts already has the proxy (proxy: { '/api': { target: process.env.DEV_PROXY_TARGET || 'http://localhost:3000', changeOrigin: true } }, server.port: 5180). examples/console-starter/vite.config.ts has no server block at all — no proxy, no pinned port (Vite default 5173). Verify both.
• ~20 read sites of VITE_SERVER_URL exist in packages/app-shell/** alone (ConditionalAuthWrapper.tsx:52, AiChatPage.tsx:374, marketplaceApi.ts:19, useAiSurface.ts:55, sharedUserFeeds.ts:524, AppHeader.tsx:303, …). Most coalesce to '', which is the same-origin shape — ⛔ verify, do not assume, and name any that do not.
• The failure mode that turns "empty it" from a fix into an outage: a read that builds ${VITE_SERVER_URL}/something-not-under-/api, which the proxy does not cover. Find those before emptying anything.
• examples/console-starter/.env.production pointing at https://demo.objectstack.ai may be deliberate — the ruling says revisit, not change. Establish which before touching it, and say what you established.

⛔ Any zero result above needs a control term known to hit, or it is not a reading. ⛔ cmd | sed … || echo "0 hits" is a broken instrument — || binds to the last command in the pipeline, so the fallback never fires; capture exit codes before any pipe. (The seat did this to itself earlier today.)

---

Generated by Claude Code

[os-zhuang]

os-dev-report

{
 "issue": 5745,
 "status": "done",
 "branch": "claude/issue-5745-one-origin-dev-configs",
 "pr": "https://github.com/objectstack-ai/objectui/pull/5765",
 "premise_still_valid": true,
 "summary": "Emptied VITE_SERVER_URL in apps/console/.env.development and examples/console-starter/.env.development, added the one-stanza /api dev proxy (DEV_PROXY_TARGET or http://localhost:3000, changeOrigin) to examples/console-starter/vite.config.ts which had no server block at all, and emptied examples/console-starter/.env.production. apps/console/.env.production and apps/console/vite.config.ts untouched; #5702's sameOriginOnly change not implemented here. ZONE 2a verified line by line: both dev envs were http://localhost:3000, page origins 5180 (pinned) and 5173 (Vite default, no server block), starter production was https://demo.objectstack.ai, console production already empty. ZONE 2b answered by full enumeration: 114 repo-wide mentions, ~50 executable read sites, each traced to the path it builds including through prop-passing consumers (FlowRunner, createConsoleServerActionHandler, createObjectStackUploadAdapter, useEnvironmentEntitlements, createIdentityImportDataSource, MetadataClient, ObjectStackAdapter) and into @objectstack/client@17.1.0's own route map. Every fetch-building site is under /api, so the proxy covers them. TWO NON-/api PATHS FOUND, both navigations not fetches, both reported not worked around: (1) packages/core/src/actions/ActionRunner.ts:1343 promotes /api/, /_auth/ and /_account/ to apiBase before a full-page window.location.href, and the last two are covered by neither proxy; reachability measured at 7 repo-wide hits, all CHANGELOG, test or doc prose, so no first-party producer exists, and /_account/* is a sibling SPA mount that App.tsx:7 records as being retired into the console SPA. (2) entitlements.ts:48 DEFAULT_UPGRADE_URL is /settings/billing, rendered as an anchor href no proxy could serve; emptying IMPROVES that site, since today it opens localhost:3000/settings/billing in a new tab while empty makes it the same-origin in-app route that production has already shipped since 2026-05-24. A third, softer class named but not solved: @objectstack/client's getRoute() prefers discoveryInfo.routes over its built-in map, and that map is 100 percent /api/v1/*, so a server could in principle advertise a route outside /api. I did NOT widen apps/console/vite.config.ts (read-only under the fence) because the /api proxy already covers every fetch site and the two exceptions have no first-party producer; reported instead. ZONE 2c: port left on Vite's default 5173 deliberately, because the starter README already documents 'no server.port is set, so the default 5173' and pinning one would collide with a real fork's choice. ZONE 2d ESTABLISHED, NOT GUESSED: the starter's committed demo origin is NOT deliberate. It is the same pre-convergence value the sibling console carried until c351c9604, 2026-05-24, 'fix(console): default published SPA to same-origin (clear VITE_SERVER_URL)', whose changeset cites CORS-blocked auth/i18n/discovery calls blanking the SPA on any host but the demo one; that commit touched only apps/console/.env.production plus its changeset and left the starter behind. Supporting: the example is private:true, on the changeset ignore list, and referenced by no workflow, vercel config or deploy (controlled grep: apps/console hits 3+ workflows, console-starter hits none); its apparent origin commit 10d2a5119 is a pure rename with 0-byte diffs, so the value predates it as a shared sibling default. NOTE: the clone was shallow at 70 commits, where git log showed one boundary commit per file, which is NOT evidence; I deepened to 4598 commits to turn this into a measurement.",
 "tests": "Union re-run at final commit 645b024cb with a clean tree; every exit code captured before any pipe, and each verdict quoted from the gate's own output rather than from $?. Gates: check-changeset-presence exit=0 'No source of a released package changed in this range, so no changeset is owed.'; check-changeset-no-major exit=0 'No changeset declares a major bump.'; check-control-bytes exit=0 'OK (scanned 4804 tracked text file(s); skipped 85 binary).'; check-doc-links exit=0 'Links are valid across 13 scan roots.'; check-lint-coverage exit=0 'lint coverage: 46/46 packages linted, 0 with outstanding errors (0 total).'; check-type-check-coverage exit=0 '45/46 via type-check, 0 known-broken' plus 'tests 41/41'. Vitest, run from the repo root with path filters per AGENTS.md and wrapped in the shared verify lock: 'Test Files 3 passed (3) / Tests 26 passed (26)', lock VERDICT command-exit 0, held 18s, waited 0s. Those three files were chosen because they are the ones that actually read the changed surface: committed-telemetry-endpoint.test.ts enumerates every committed .env* via git ls-files and parses it from disk, vite-alias-closure.test.ts reads console-starter/vite.config.ts, runtimeConfigBootDedup.test.ts pins the %VITE_SERVER_URL% HTML substitution including the empty case. Gates derived from this repo's own workflows, since objectui has no scripts/pm and objectstack's dispatch-gates.mjs is inapplicable; node-esm-load-gate.yml and check-links.yml were checked and do NOT run on pull_request, so they are not owed. PRIMARY EVIDENCE, a measured before/after of what a relative action target resolves to, computed off the real env files (before read from git at the merge-base, after from the working tree) using the resolution rule copied verbatim from useConsoleActionRuntime.tsx:326 plus :346: apps/console page origin 5180, target /api/v1/data/lead/query, BEFORE http://localhost:3000/api/v1/data/lead/query same-origin false, AFTER /api/v1/data/lead/query same-origin true, covered by proxy true; console-starter page origin 5173 identical shape, proxy keys read out of the config as [\"/api\"]. END TO END: booted the starter's real Vite dev server against a recording stub backend and curled the page origin; HTTP 200, body {\"ok\":true,\"sawPath\":\"/api/v1/data/lead/query\"}, and the stub recorded HITS=[{\"method\":\"GET\",\"url\":\"/api/v1/data/lead/query\",\"host\":\"localhost:39311\"}], so the new stanza demonstrably forwards. ABLATION: no rebuild step exists or is needed for this one, and that is a property of the subject rather than an omission, because Vite reads vite.config.ts directly at startup with no dist involved; there is no packaged artifact between the edit and the run. The mutation was confirmed ON DISK by marker count, not by the edit command's exit code: after taking origin/main's config the injected marker DEV_PROXY_TARGET was 0 occurrences and the '^ server:' marker 0, while the control marker workspaceAliases was still 2. The restore leg was likewise proved on disk, by git status --porcelain coming back empty against my own commit; the whole mutation, measurement and restore ran inside one shell under a trap on EXIT INT TERM, after an earlier attempt showed the trap firing at the end of each separate Bash call. I stated the predicted direction before running: hits drop to zero while HTTP stays 200. Observed exactly that: HTTP=200 unchanged, body '<!doctype html>' which is the SPA index.html fallback rather than JSON, and HITS=[]. So the HTTP status is a false-green signal here and the stub hit count is the discriminating one, which is also the hazard in miniature: without the proxy an empty VITE_SERVER_URL returns HTML with a 200 instead of failing loudly. LINT NARROWING IS A MEASUREMENT, NOT A SKIP, all three parts present: (1) the universe was read from eslint itself rather than guessed, by asking it about each of the 5 changed files, and it reports 4 as ignored and 1 as linted; (2) the count came from --format json, 'files linted: 1, errors: 0, warnings: 0'; (3) eslint.config.js declares no projectService and no parserOptions.project (grep exit 1, controlled by 'rules' hitting 10 times in the same file), so type-aware linting is off and this diff cannot move the verdict on any untouched file. Independently check-lint-coverage reports 46/46 packages clean. Separately, process.env in the starter's vite config is safe: tsc --showConfig reports that program as 2 files, src/App.tsx and src/main.tsx, with 'includes vite.config.ts: false', matching the __dirname already in that file, and eslint does lint it and is clean. Zero results were controlled throughout rather than read as clean: no localhost:3000 survives in any yml/mjs/json (control: the same instrument hits 146 files for 'objectui' and finds many other localhost ports); console-starter appears in no workflow or deploy config (control: apps/console hits 3+ workflows); entitlements.ts had no 'url:' literal (control: 'cta' hits 5 times in that file, which then led to DEFAULT_UPGRADE_URL). Changeset: empty frontmatter, the repo's first-class 'declares no release' form, correct here because no released package's src/ is touched, .env.development is not in @object-ui/console's published artifact (files: [dist], built from the untouched .env.production), and the example is private and on the ignore list; objectui has no skip-changeset label and none was created or applied. NOT RUN and not claimed: the full repo-wide pnpm lint and pnpm test farms, which CI runs exactly once regardless; and the three gauges the dispatch names as known-broken in a worktree (check-eager-closure-budget, check-doc-snippet-types, check-published-dist-tooling). Build Docs is expected to report a roughly 10-second skip because this diff touches neither apps/site nor content, and per the dispatch that skip must not be read as 'the docs site builds'.",
 "open_questions": [
 {
 "question": "Should the dev proxies be widened from /api to also cover /_auth and /_account, the two non-/api path families ActionRunner.ts:1343 builds off the server origin? Surfacing rather than solving, per the dispatch's instruction to report a non-/api read instead of working around it. It does not block this card: the repair is correct without it.",
 "options": [
 "A. Leave both proxies at /api and fix the doc instead. No first-party producer of a /_auth/ or /_account/ action target exists today (7 hits, all CHANGELOG/test/doc), /_account/* is a sibling SPA mount that App.tsx:7 records as being retired into the console SPA, and apps/console/vite.config.ts is read-only under this card's fence.",
 "B. Widen apps/console/vite.config.ts and examples/console-starter/vite.config.ts to proxy /api, /_auth and /_account. Makes apps/console/README.md:54 true for the first time and closes the gap before the sameOriginOnly default lands, at the cost of proxying two path families nothing currently targets.",
 "C. Leave one or both dev envs non-empty and accept a partial convergence. Rejected on measurement: that keeps roughly 50 read sites cross-origin to protect two navigation paths with no producer, which is the trade the ruling exists to stop."
 ],
 "recommendation": "A, because the evidence makes B speculative surface rather than a fix: every path family that actually carries traffic today is under /api and already covered, the two exceptions are top-level navigations rather than the bare-fetch lane #5702 is about, and /_account is documented as being retired into the console SPA, so proxying it to the backend would entrench a mount the codebase is moving away from. The real defect in that area is a doc that claims coverage which never existed, and that is filed as #5766 with both routes written up so triage can pick B instead if the maintainer wants the symmetry."
 }
 ],
 "out_of_scope_findings": [
 "filed as #5766: console and console-starter READMEs state VITE_SERVER_URL dev defaults this PR makes stale (examples/console-starter/README.md backend table; apps/console/README.md:36 and :53), and apps/console/README.md:54 claims Vite proxies /api/* and /_account/* when vite.config.ts:709-711 proxies only /api (that last one pre-existing). Left unfixed only because the READMEs sit outside this card's write fence; both resolution routes written up. Say the word and I will fold the doc half into PR #5765."
 ]
}

---

Generated by Claude Code