titah web
# http://127.0.0.1:53211titah web starts the server and opens a browser at it. The server has been
headless since M1; this is a client for it, exactly as the TUI is.
No new routes
The page uses precisely the API the TUI uses. Nothing was added to the server for it — see HTTP API for every route it calls.
/ answers two things depending on Accept: HTML for browsers, the /health
JSON payload for everything else. Splitting them by content negotiation rather
than by inventing a path keeps one question — what is here? — with one route,
and lets the answer differ by who is asking. /health stays JSON
unconditionally, so a health checker never guesses.
No build step
The client is embedded as a string in the binary. No bundler, no asset directory, no relative paths to resolve.
Assets that have to be copied into place and then found at runtime are three new ways to fail on someone else’s machine, for a page that is one file.
It loads nothing from outside itself, and text coming back from the model is
escaped before it reaches innerHTML.
Permission and questions are answered on the page
This is what makes it a client rather than a viewer. Without it the page would only read, and every turn that touched a file would hang until it timed out — because with no client able to answer, a dialog is auto-denied.
What it is not
It is not the TUI in a browser.
| Present | Absent |
|---|---|
| Session list | The sub-agent panel |
| History and streaming answers | Undo |
| Sending prompts | The model picker |
| Answering permission requests and questions | The skill picker |
| Stopping a running turn | The command palette |
Keyboard use works for what is there: the session list is focusable and Enter
sends.
!!! danger “There is no authentication”
titah web binds to 127.0.0.1 and titah serve has no auth layer in v1.
A server on a public interface hands anyone a shell in your working
directory, subject only to your permission config.