Web GUI
The Web GUI is the browser target of the GUI. It shares one view tree with the Desktop GUI but is not served by the agent: it is hosted on the release channel (R2) and talks to one agent behind the GUI origin.
Hosting
Section titled “Hosting”gui/index.html and the wasm bundle (with Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp) are published to
the release channel. A same-origin reverse proxy in front of R2
(infra/caddy/gui.caddy) runs oauth2-proxy and forwards X-Auth-User to the
agent process — not the bearer-gated agent nginx /api.
Because the GUI and /api are served from one origin, the browser session is a
signed cookie (sf_session), so the Web GUI carries no bearer token.
What it can do
Section titled “What it can do”- Dashboard — environment health, capacity, active work.
- Chat — operator Q&A with streamed replies (SSE); thinking collapses into an accordion; chats can be deleted.
- Board — issue-rooted Kanban plus the local backlog.
- Config — settings with inline typed editors, credentials, health checks, skills.
- Audit — state mutations.
The Web GUI uses a GitHub OAuth login against the agent’s GUI origin and a session cookie. If the session is rejected the GUI shows a sign-in gate. Sign-in always targets the page origin — never a remote selected agent, because a cookie set on another origin is one the GUI can never read.
Desktop clients have no cookie session and use a pasted token instead; see Desktop and Auth.
Building the wasm bundle
Section titled “Building the wasm bundle”make gui-wasm # cargo +nightly build ... --target wasm32-unknown-unknown, then wasm-bindgenThe release workflow builds and publishes the wasm bundle automatically; a broken or missing bundle fails the release closed.