Self-host: local console sign-in without Cloudflare Access (follow-up to #95 / #104)

[b3nw]

#104 shipped the Docker self-host profile (thanks!) and listed console sessions as its main v1 limitation:

Self-host v1 has no console sessions (Cloudflare Access absent); documented as a limitation with the admin-API workflow. A token-based console login could follow if demand materializes.

Registering that demand. Running the profile from #95, the admin bearer-token API covers scripted management, but day-to-day operation wants the console: policy/grant editing, readiness, usage, playground, and the self-service maintainer keys from #103 are all dead in a browser because the dashboard fail-closes without an Access identity.

Proposal — the token-based login sketched in #104, kept minimal:

• POST /v1/session/login exchanges the existing admin token (verified against CLAWROUTER_ADMIN_TOKEN_SHA256 — no new secrets) for a KV-backed, HttpOnly session cookie; POST /v1/session/logout revokes it. Sign-in attempts rate limited.
• verifiedAccessSession resolves the cookie alongside Cloudflare Access, so every session consumer (dashboard, playground, /v1/session/*, maintainer keys) works unchanged.
• Fail-closed on managed deployments: requires an explicit CLAWROUTER_LOCAL_AUTH flag and is refused whenever CLAWROUTER_ACCESS_* is configured. Cloudflare path untouched.
• Console renders a sign-in form when the session bootstrap 401s and the service index advertises the login endpoint.

Have this implemented and verified end-to-end (workerd + headless-browser flow, full CI green on my fork); PR to follow.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 2, 2026, 3:10 PM ET / 19:10 UTC.

Summary
This issue remains necessary: current main deliberately leaves the self-host dashboard and session APIs unavailable without a Cloudflare Access identity, and the requested opt-in local-auth feature is owned by the linked open pull request. The new admin-token-to-browser-session boundary needs maintainer approval before that implementation can land.

Reproducibility: yes. from current source: start the documented self-host profile without Cloudflare Access and request a dashboard or session endpoint; verifiedAccessSession cannot resolve an identity and the Worker returns the documented fail-closed 401. A live execution was not run because this review is read-only.

Maintainer decision needed

Question	Recommendation
Should the supported self-host profile accept the existing admin bearer token through an opt-in browser login endpoint that mints a local HttpOnly session cookie?	Approve the constrained local-auth path: Accept the opt-in, self-host-only session model if the linked pull request's Access exclusion, CSRF, rate-limit, revocation, and upgrade guarantees are confirmed.

Why: This is not a repair to an established browser-auth contract: it introduces a privileged credential-to-session conversion and a new self-host configuration mode, so maintainers must set the acceptable security and product boundary.

Next step
Do not queue a duplicate repair because #106 already owns the implementation; resolve the maintainer security and product decision on that PR.

Security
Needs attention: The issue proposes a new privileged authentication boundary, so the linked implementation requires maintainer security review before merge.

Review details

Best possible solution:

Approve a narrow, opt-in local-auth contract for the supported single-process self-host profile, then review and land the linked pull request with focused Worker, admin, entrypoint, and browser-flow validation while preserving the default API-only posture.

Do we have a high-confidence way to reproduce the issue?

Yes, from current source: start the documented self-host profile without Cloudflare Access and request a dashboard or session endpoint; verifiedAccessSession cannot resolve an identity and the Worker returns the documented fail-closed 401. A live execution was not run because this review is read-only.

Is this the best way to solve the issue?

Unclear pending maintainer approval: the linked pull request is a focused implementation with stated live proof, but accepting an admin-token-to-cookie authentication boundary is a product and security decision rather than a mechanically implied bug fix.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Accepting an admin bearer token through a browser login route creates a privileged session-issuance boundary that needs an explicit decision on the intended threat model and operational posture.
• The linked implementation adds a new configuration mode and cookie-backed session persistence; its stated opt-in and Access-configured refusal reduce upgrade risk, but maintainers must verify those guarantees before merge.

Codex review notes: model internal, reasoning high; reviewed against c4002ddb154e.

Label changes

Label justifications:

• P2: The missing self-host console path affects ordinary administration but retains the documented bearer-token API workflow.
• impact:auth-provider: The requested behavior changes how an administrator authenticates and how sessions are resolved.
• impact:security: The proposal turns an existing high-privilege admin token into a browser session credential.
• impact:ux-friction: Self-host operators can manage the service through the API but cannot use the normal browser console today.

Evidence reviewed

Security concerns:

• [medium] Review the token-to-session boundary
  The requested login endpoint would exchange the existing administrator bearer token for a persistent browser session, which needs an explicit decision on exposure, CSRF, rate limiting, session revocation, and self-host deployment assumptions.
  Confidence: 0.97

What I checked:

• Current self-host behavior: The self-hosting guide explicitly says Cloudflare Access is absent and that console sign-in plus dashboard and Access-session endpoints remain fail-closed without an Access identity. (docs/self-hosting.md:101, c4002ddb154e)
• Current Worker enforcement: The dashboard shell calls the verified Access-session resolver and returns access_session_required when no session is present; the same resolver requires both the Cloudflare Access assertion and Access configuration. (worker/index.ts:85, c4002ddb154e)
• Self-host configuration has no local-auth mode: The self-host entrypoint requires and forwards only the SHA-256 admin-token digest; a repository-wide search found no current-main local-auth flag, login endpoint, or service-index login advertisement. (deploy/self-host/entrypoint.mjs:50, c4002ddb154e)
• Feature provenance: The documented self-host limitation dates to the Docker self-host implementation, introduced by Peter Steinberger in the release-era commit that added the profile. (docs/self-hosting.md:101, 1f74535480fc)
• Release and main check: The available release tag v0.1.0 contains the self-host profile and its explicit no-console-session limitation; current main is at c4002dd and has only later changelog, workflow, and dependency commits in the available history, not this feature. (docs/self-hosting.md:99, c4002ddb154e)
• Open implementation owner: The provided issue timeline and linked pull-request context show an open, cleanly mergeable implementation candidate with real self-host proof; it must be reviewed and merged rather than treated as a completed fix.

Likely related people:

• Peter Steinberger: Introduced the Docker self-host profile and the documented Access-dependent console limitation; current main history for the central self-host and session files is attributed to this work. (role: self-host profile introducer and recent adjacent contributor; confidence: high; commits: 1f74535480fc, c4002ddb154e; files: docs/self-hosting.md, deploy/self-host/entrypoint.mjs, worker/access.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.