Skip to content

openpalm admin — serve the host UI from the CLI (host-ui mode, Phase 1.5) #556

Description

@fwdslsh-dev

Summary

Add openpalm admin: the CLI serves the existing host UI with the admin capability enabled, loopback-only, using the existing op_session password auth, and opens the browser. This is the host-ui mode from docs/technical/ui-runtime-modes-plan.md (Phase 1.5) — full host management from a browser on the host machine without Electron.

Why now

  • Today the CLI serves the UI (packages/cli/src/lib/ui-server.ts) but never sets OP_INSIDE_ELECTRON / OP_ENABLE_ADMIN, so /admin/* redirects away — full admin is Electron-only, by accident rather than by decision.
  • The gap between "what exists" and "what's needed" is a few lines of spawn-env plus a subcommand: the loopback bind, the password gate, and the supervisor all already exist.
  • Loopback-only CLI-launched admin web UIs are a proven pattern (Syncthing, code-server, Prisma Studio, Drizzle Studio — all default to 127.0.0.1 with explicit opt-in exposure).

Scope

  • openpalm admin subcommand: spawn the UI server with admin enabled (today: OP_ENABLE_ADMIN=1; after UI Runtime Modes: RuntimeContext v2 + capability system (replaces FeatureFlags) #509 lands: hostMode: 'host-ui'), print the URL, open the browser
  • Loopback-only, always — this mode refuses non-loopback binds (no OP_ALLOW_REMOTE_SETUP interplay)
  • On a machine with no install yet, lands on /setup (same wizard flow as openpalm install)
  • Docs: docs/how-it-works.md harness section mentions the third way to reach admin (Electron, openpalm admin, and — dev only — OP_ENABLE_ADMIN=1)

Non-goals

  • No new UI, no new auth mechanism, no remote exposure. This is plumbing for the existing surface.

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions