AI Anywhere: a browser dashboard for tmux agent sessions

Who AI Anywhere is for, and the problem it addresses

Agent CLIs are terminal programs. They run in a shell, they hold state in that shell, and they keep running whether or not anyone is watching the terminal window. That is fine when you are at the machine. It stops being fine when you are not. The README frames the problem directly: AI Anywhere brings agent CLI sessions running in tmux to a focused browser interface that works on desktop and mobile, and the web UI collects every task that needs attention without moving terminal state away from the machine where it is running.

That last clause is the design constraint, not a marketing line. The terminal state stays put. The browser is a viewing and control surface for sessions that continue to live in tmux on the host. This matters for anyone who runs long agent tasks and wants to check in from a phone, a second laptop, or a browser on the same network without SSHing in and reattaching by hand.

The intended user is someone who is already comfortable with tmux and agent CLIs. There is no claim that AI Anywhere replaces the terminal or abstracts away tmux. It is a web layer over sessions you already have. If you do not run tmux, the premise does not apply to you.

What this repository actually contains

The single most important fact about AI-Anywhere/AI-Anywhere is that it is not the runtime. The README states that the CLI, tmux integration, local server, and browser workspace live in the AI Anywhere core repository, and that this repository is the canonical source for the tmux.online website. The package.json name is aa-www and its description reads "tmux.online - static marketing site". That is the honest scope.

So what is here? The public product site, the React account dashboard, device authorization and membership screens, the shell installer, and Cloudflare Worker and deployment configuration. The README lists the routes: the English product site at /, localized sites at /ja, /ko, and /zh-Hant, dashboard routes for devices, API keys, membership, and device authorization, a cookie-aware compatibility redirect at /device, and the installer at /install.sh.

The architecture table is specific. Public pages are Astro, prerendered HTML with inline critical CSS. The dashboard is React with React Router and SWR. The account API is https://api.tmux.online through a typed client in src/lib/api.ts. Localization uses typed copy tables in src/i18n. The edge runtime is a Cloudflare Worker in worker/index.js. Response policy comes from public/_headers and Worker response headers, and deployment runs through Wrangler and GitHub Actions.

One detail worth noting: the public pages do not load a framework runtime, and React hydrates only the dashboard and device authorization surfaces that need account state. That is a deliberate split, and it means the marketing site stays static while the account surfaces pay the React cost.

Installing AI Anywhere and starting the local service

Installation is a single shell command, run on the machine that hosts your tmux sessions. The README gives this example:

curl -fsSL https://tmux.online/install.sh | sh

The README states that the installer verifies local prerequisites, installs @ai-anywhere/cli, and starts AI Anywhere. The server listens on 127.0.0.1 by default, so terminal traffic remains on the local machine. Expect the installer to check for prerequisites on your host and to leave you with a running local service bound to loopback. If any prerequisite is missing, that is where the run stops.

If you want to work on the website itself rather than run the product, the repository uses pnpm. From a checkout:

pnpm install
pnpm dev

The README says the development server runs at http://localhost:4321. To point the site at a local account API instead of the hosted one:

PUBLIC_API_URL=http://localhost:51994 pnpm dev

The other scripts are listed in the README and in package.json: pnpm build generates the production site in dist/, pnpm preview serves that output, pnpm check runs Astro and TypeScript checks, pnpm lint checks formatting and Astro types, pnpm format applies repository formatting, and pnpm images regenerates raster images from source assets. Deployment is pnpm deploy, which builds and then runs wrangler deploy.

Note the split in what you get. The installer gives you the product: a CLI and a local service. The pnpm commands give you the website. They are not the same thing, and the README keeps them apart.

The localization registry and the L cookie

English is served without a URL prefix, and Japanese, Korean, and Traditional Chinese use their own path prefixes. The README describes a locale registry that feeds the language switcher, alternate links, Open Graph metadata, the sitemap, and machine-readable text pages. Adding a language means adding a typed copy file under src/i18n, registering the locale and its Open Graph locale in src/i18n/index.ts, adding a matching page directory under src/pages, and checking typography and text fit on both mobile and desktop layouts.

The L cookie is the part worth understanding before you debug a redirect. The README describes it as a non-sensitive, root-domain preference readable by tmux.online services. It records the active language so compatibility routes can select the correct location. The bare / home follows a saved non-English preference, and unknown values fall back to English. So a device authorization flow can return a user to the correct localized dashboard route rather than dumping them on the English page.

The trade-off is that language selection is partly server-side state carried in a cookie rather than purely in the URL. That is what makes the compatibility redirect at /device work, but it also means two browsers with different cookie values can land on different pages from the same link.

Dashboard caching and why account routes are excluded from search

The README is unusually explicit about caching and indexing, and this is where the project's privacy posture is visible. Dashboard HTML is cached privately in the browser for ten minutes and is explicitly excluded from Cloudflare edge caching. Account data is fetched in the browser after the session is resolved. Dashboard routes are excluded from search indexing through HTML, response headers, robots.txt, and sitemap filtering.

Four separate mechanisms for one goal is more than most sites bother with, and it tells you the authors treat account pages as something that must not end up in an index or a shared edge cache. The ten-minute private browser cache is a deliberate trade: faster back-and-forth navigation inside the dashboard, at the cost of a stale view for up to ten minutes. If you expect a device you just revoked to disappear from the list instantly, that is the window where it may not.

For a self-hoster, the takeaway is that the response policy is not implicit. It lives in public/_headers and in Worker response headers, so if you fork the site and change the deployment, you own those rules. Nothing in the README suggests the Worker enforces them independently of that configuration.

The repository boundary is the real limitation

The biggest constraint is not a bug. It is scope. If you clone AI-Anywhere/AI-Anywhere expecting the tmux integration, the local server, or the CLI, you will not find them. The README states plainly that changes to the CLI, local service, tmux protocol, or npm package belong in the AI Anywhere core repository, and that the website consumes those runtime artifacts through the public installer and documented HTTP interfaces.

That has practical consequences. An issue about session handling belongs in core, not here. A fix to the installer script in public/install.sh does belong here, but a fix to what the installer downloads does not. Anyone evaluating the project for adoption should read both repositories, because this one only tells you how the web layer is built.

There are other gaps. The licence is not stated in the repository files available, which means you cannot confirm the terms under which you may use, modify, or redistribute the code. The README does not document rollback, uninstall, or what happens to running sessions when the local service stops. There are no retrieved releases, so there is no changelog to check for breaking changes. And the README does not document authentication details for the local server beyond the fact that it binds to 127.0.0.1 by default, which is the right default but is also the only access control the README describes.

How it compares with ttyd and with SSH plus tmux

The obvious alternative is ttyd, which shares a terminal over HTTP and is commonly paired with tmux. The difference is in what the interface is for. ttyd gives you a terminal in the browser: you see the same character grid you would see in a terminal emulator, and you interact with it the way you interact with a shell. AI Anywhere, based on the README, builds a dashboard that collects every task that needs attention, with separate account surfaces for authorized devices, API keys, and membership. It is a task-oriented view over sessions, not a terminal emulator in a tab.

That distinction decides which one you want. If your work is interactive and you need to type into a shell from a browser, ttyd is the closer fit, and it is a single small binary with no account layer. If your work is a set of long-running agent sessions you check on periodically, a dashboard that surfaces what needs attention is a better shape, and that is what AI Anywhere claims to provide.

The second alternative is what most people already do: SSH into the host and run tmux attach. It requires no new service, no installer, and no account API. It also requires a terminal client on whatever device you are holding, which is exactly the friction AI Anywhere is trying to remove on mobile. The honest comparison is that AI Anywhere adds a network-facing service and an account layer to solve a mobile ergonomics problem. If you do not have that problem, the simpler option wins.

Maintenance, upgrades, and licence

The last push to this repository was on 2026-09-11, which is recent. That is the only maintenance signal available, and it applies to the website layer. It says nothing about the cadence of the core repository, which is where the CLI and local service live and where upgrade risk actually sits.

Upgrade cost is split along the same boundary. The website deploys through Wrangler and GitHub Actions, and the workflow in .github/workflows/deploy.yml deploys pushes to main using two repository secrets, CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID. The README states those values belong in GitHub repository settings and must never be committed. If you self-host the site, you own that pipeline and those secrets. The CLI side upgrades through @ai-anywhere/cli, and the README does not describe a version pinning or rollback procedure, so you should decide how you will pin before you start.

On licensing: the repository files available do not state a licence for this repository. That is a real gap for anyone planning to fork or redistribute it, and it is not something to assume. Check the repository's licence file directly before you build anything on top of the code. Nothing here is legal advice, and no licence identifier should be inferred from the README.

Editorial conclusion

Adopt AI Anywhere if you already run agent CLI sessions inside tmux on a machine you control and want to check on them from a phone or another browser without moving terminal state. Do not adopt it if you expect the local service, tmux protocol, or CLI to live in this repository: the README states those belong in the AI Anywhere core repository, and this repo is only the tmux.online web layer. Before installing, verify three things: that the core repository is reachable, that the installer at https://tmux.online/install.sh is the one you expect to pipe into sh, and that the server binds to 127.0.0.1 on the host that holds your sessions. The account API endpoint is https://api.tmux.online, and the README does not document rollback or uninstall steps, so decide how you will remove @ai-anywhere/cli before you install it.

Frequently asked questions

Official sources

1. AI-Anywhere/AI-Anywhere on GitHub
2. Issues
3. Project website
4. README