AI Anywhere: a browser front end for tmux agent sessions

What AI Anywhere actually is, and what it is not

The README opens with a promise: "Your agents. Any browser. Anywhere." The scope is narrower than that slogan suggests, and the repository boundary section says so plainly. This project is the web layer served at tmux.online: the public product site, the React account dashboard, device authorization and membership screens, the shell installer, and the Cloudflare Worker and deployment configuration. The CLI, the tmux integration, the local server and the browser workspace live in a separate repository, AI Anywhere core.

That split defines the audience. You are the right reader for this repository if you already run agent CLI sessions inside tmux on a machine you control and you want to check on them from a browser, including a phone browser, without moving terminal state off that machine. You are the wrong reader if you are looking for a browser extension, an APK, or a hosted service that runs agents for you. None of those appear in the README, the routes table, or the package manifest. The npm package this site installs, @ai-anywhere/cli, is published from the core repository, not from here.

The problem being solved is attention, not compute. Agent CLI sessions accumulate in tmux windows, and the README describes the goal as collecting "every task that needs attention" into one interface. The dashboard routes match that framing: /dashboard/devices, /dashboard/api-keys, /dashboard/membership and /dashboard/device are account and authorization surfaces, not a terminal emulator.

The Astro and React split, and why the dashboard is not prerendered

The architecture table separates two rendering paths. Public pages are Astro, prerendered to HTML with inline critical CSS, and the README states that they do not load a framework runtime. React hydrates only the dashboard and device authorization surfaces that need account state. That is a deliberate cost trade: marketing pages stay cheap to serve, and the interactive parts pay for their JavaScript only where it is needed.

The dashboard is client-rendered with React Router and SWR, talking to an account API at https://api.tmux.online through a typed client in src/lib/api.ts. Account data is fetched in the browser after the session is resolved, which is why the HTML can be cached while the data cannot. Dashboard HTML is cached privately in the browser for ten minutes and explicitly excluded from Cloudflare edge caching. The README also lists browser-side caching for dashboard navigation, which is the SWR layer doing its usual job.

Privacy handling is spread across four mechanisms rather than one: HTML, response headers, robots.txt, and sitemap filtering all exclude dashboard routes from search indexing. The response policy lives in public/_headers and in the Worker's response headers. That redundancy is reasonable for account routes, though it does mean a change to indexing rules has to be applied in several places, and the README does not describe a test that would catch a missed one.

Localization is registry-driven. Typed copy tables live in src/i18n, and the README says the language switcher, alternate links, Open Graph metadata, sitemap, and machine-readable text pages all derive from the same locale registry. English is served without a prefix; Japanese, Korean and Traditional Chinese use path prefixes such as /ja, /ko and /zh-Hant. The L cookie is described as a non-sensitive, root-domain preference that records the active language so compatibility routes can pick the right location. Unknown values fall back to English.

Installing AI Anywhere on the tmux host

The installer runs on the machine that hosts your tmux sessions, not on the machine where you open the browser. The README gives one command for it. The installer verifies local prerequisites, installs @ai-anywhere/cli, and starts AI Anywhere.

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

Two details in the README are worth reading before you run that. The server listens on 127.0.0.1 by default, so terminal traffic stays on the local machine; reaching it from another device is a separate question the README does not answer here. And the installer itself is the file public/install.sh in this repository, downloadable at the /install.sh route, so you can read the script before piping it into a shell.

If you want to work on the web layer rather than use it, the project uses pnpm. Install dependencies and start the dev server, which the README says runs at http://localhost:4321.

pnpm install
pnpm dev

To point the dashboard at a local account API instead of the production one, set PUBLIC_API_URL when starting the dev server.

PUBLIC_API_URL=http://localhost:51994 pnpm dev

The other scripts are build, preview, check, lint, format, images and deploy. Note that lint is not just a linter: it runs scripts/check-ascii.mjs, then prettier --check, then astro check. If a contributor's editor inserts a non-ASCII character somewhere the script disallows, lint fails before formatting is even considered.

Deployment runs through Wrangler, and the secrets are the sharp edge

Deployment is pnpm deploy, which the package manifest defines as astro build followed by wrangler deploy. The Worker lives in worker/index.js and the Wrangler configuration in wrangler.jsonc. Pushes to main are deployed by the GitHub Actions workflow in .github/workflows/deploy.yml, which expects two repository secrets: CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID. The README is explicit that secret values belong in GitHub repository settings and must never be committed.

There is a real failure mode here that the README does not document. Because deploy is a single script that builds and then deploys, a broken build and a broken upload look the same from the outside until you read the logs. There is also no documented rollback procedure, and the repository has no releases retrieved, so there is no tagged artifact to fall back to. If you adopt this for a production site, you are relying on Cloudflare's own versioning rather than anything this project provides.

The Worker sits in front of both the static assets and the response policy. That means the edge runtime is on the critical path for header behaviour, and a Worker change can affect caching and indexing rules for pages that are otherwise static. The README lists the Worker under response policy alongside public/_headers, which is the honest description: two places decide what headers a response carries.

Where the documentation stops: the core repository

The most important limitation is not a bug. It is that this repository cannot tell you how the tmux integration works. The README states that changes to the CLI, local service, tmux protocol, or npm package belong in AI Anywhere core, and that the website consumes those runtime artifacts through the public installer and documented HTTP interfaces. Everything about how a session is discovered, how the browser workspace talks to the local server, and what the local server's configuration surface looks like is out of scope here.

That has practical consequences. If the installer fails on your machine, the troubleshooting path leads to the core repository, not this one. If you want to know whether the local server can bind to something other than 127.0.0.1, or what ports the CLI uses, the README here does not say. The account API is documented only as a base URL and a typed client file; the shape of the endpoints is not in this material.

The licence is also unstated. No license file appears in the top-level entries, and the repository metadata does not identify one. For a project that ships an installer you pipe into a shell, that is a gap worth closing before adoption, and it is not a gap this article can fill.

One more boundary: the account surfaces imply a service behind them. Device authorization, API keys, trials, referrals and permanent membership are all listed as dashboard features, which means the dashboard is useful to the extent that api.tmux.online is available. Self-hosting the web layer is possible, since the code is here and PUBLIC_API_URL is configurable, but the README does not describe running the account API yourself.

How it compares with running tmux over SSH or through a web terminal

The obvious alternative is what most people already do: SSH into the host and attach to tmux directly, or run a general web terminal such as ttyd or gotty in front of it. The difference in approach is what gets modelled. SSH and web terminals expose a terminal; you get a shell and you navigate tmux yourself. AI Anywhere instead builds an account dashboard around the sessions, with device authorization, API key management and membership views, and it targets desktop and mobile browsers as first-class surfaces.

That trade cuts both ways. A web terminal is agnostic about what runs inside tmux, and it needs no account layer. AI Anywhere assumes a specific kind of workload, agent CLI sessions, and assumes you want a curated view of which ones need attention rather than a raw terminal. If your sessions are not agent CLIs, or if you prefer to see the terminal exactly as it is, the dashboard adds a layer without adding much.

A second comparison point is the rendering strategy itself. Astro with mostly prerendered HTML and React hydrated only on account surfaces is a lighter approach than a single-page app that ships a framework runtime for every page. The README leans on this explicitly when it says the public pages do not load a framework runtime. If you are evaluating the codebase as an example of that pattern, the split between src/pages, src/islands and src/components is the part to read.

Maintenance and upgrade cost

The last push to this repository was on 2026-09-11, three days before this writing, so the codebase is being touched. There are no retrieved releases, which means versioning happens through commits and the deployment pipeline rather than through tagged artifacts you can pin.

Upgrade cost concentrates in three places. The dependency set includes Astro 7, React 19, React Router 7, SWR 2 and Wrangler 4, all as caret ranges, so a fresh install can pull newer minor versions than the lockfile was built against unless you install with the lockfile. The lint script runs astro check and prettier, so a framework upgrade that changes types will surface as a lint failure rather than a runtime error, which is a mild advantage. And the localization registry means adding a language touches four places: a copy file under src/i18n, a registration in src/i18n/index.ts, a page directory under src/pages, and a typography and text-fit check on mobile and desktop.

On licensing, the repository does not state a licence, so there is nothing to summarize about permissions, obligations or redistribution terms. That is a fact about the material, not a legal opinion, and it is the first thing to resolve if you plan to reuse any of this code.

Editorial conclusion

Adopt AI Anywhere if you already run agent CLIs inside tmux on a machine you control and want a mobile-friendly dashboard for them. Do not adopt it if you need a hosted service, a browser extension, or a desktop app: this repository is the website and dashboard, and the CLI, tmux protocol and local server live in the separate AI Anywhere core repository. Verify two things before you commit. First, read the core repository's documentation, since the README here does not document the tmux protocol or the server's configuration surface. Second, check the licence, because the repository does not state one.

Frequently asked questions

Official sources

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