The tower

A local-first surface for managing many Claude Code sessions. Each session runs the full Claude Code TUI in a real PTY (its fullscreen renderer, whatever your own tui setting, so the mouse wheel scrolls Claude's transcript), owned by a detached host that appends everything about it to a log. Everything a view shows is derived from those logs, so renderers are swappable: today the tower page, Tower 3D, The Week and the tower command.

A personal experiment, in daily use. Local only: no accounts, no external services. macOS (it reads ps -E, lsof and launchd re-parenting).

No guarantee it keeps working: it drives Claude Code's TUI, hooks and mods, and a future Claude Code version may break it. The point of the project is its primitives and disposable renderers, for you to shape to your liking. It doesn't try to solve everyone's problems or to design specific workflows.

Three views of the same data ship with it: the tower page, Tower 3D, a first-person office where every worker has a desk, and The Week (/r/week/), the budget week read as a yearbook. They read the same board and the same API, and so can a renderer of your own.

Requirements

• macOS
• Node ≥ 24
• Claude Code 2.1.292 or later, signed in (tested up to 2.1.296; tower doctor and the board say when yours is outside that range)
• git and curl (Xcode's command line tools)
• Optional: VS Code's code on the PATH, or another editor set in the config, to open projects and files from the tower

Run

git clone https://github.com/RegiByte/the-tower.git tower && cd tower
npm run setup        # install, write a first config, check the machine, start everything
open http://127.0.0.1:4317

npm run setup -- <dir> [repos...] makes <dir> the first project in place of this checkout; --tower3d also builds Tower 3D (npm run tower3d any time later, then open /r/tower3d/).

npm link puts the tower command on your PATH (it is also on the PATH of every session the tower runs):

tower up | down [host|terms|tower]   # start or stop the host, the terms daemon and the tower, detached
tower doctor                         # check what the tower needs, with a fix for each failure
tower config check                   # check the config as the tower reads it, each problem at its key
tower update                         # move to the newest release, restart the tower, say if the host needs a restart
tower init [hub] [repos...]          # write a first config, never over one
tower spawn <project> [--cwd <dir>] [--model <m>] [--effort <e>] [-- <prompt>]
tower ls | live | ps | reap [id] | resume <id> | submit <id> <text> | kill <id|CALLSIGN> | screen <id> [t] | attach <id>
tower app                            # open the tower as a Mac app (built on first use; needs xcode-select --install)

The host owns every session and the terms daemon every shell: stopping either ends them (sessions can be resumed). The tower is only a view of them, restarted freely with tower down tower && tower up tower. Releases are tags vX.Y.Z, each with an entry in CHANGELOG.md saying what it asks of you.

The browser is the default; tower app is the same tower in a window of its own, over the system you started with tower up (it waits for one until you do). It shows who waits on you on its Dock icon, in notifications and in the menu bar, and quitting it leaves the system running. Built from your checkout, it stays yours: drag apps/macos/out/Tower.app to the Dock to keep it there.

Use

Talk to your workers: "show me the page you built", "hire a worker for the flaky tests", "check on HOLMES-42", "get yourself reviewed when you're done", "keep that idea as a draft". docs/usage.md walks through what the tower makes possible: setting up your floors (a project's hub and repos), showing, hiring, checking on workers, review threads, collections, the shelf, resume, Tidy, shells, Stats, Tower 3D and renderers of your own.

New to it? Ask any worker "show me how to use the tower": it gives you a tour of your own floors.

To customize it (your own renderer, a copy of one that ships, shelf pages, scripts over the API, your own kinds of files), read docs/extending.md: every extension point, its contract, and what isn't one.

Config

~/.tower/config.json (TOWER_CONFIG points elsewhere; its directory is the system root, where logs and sockets live). tower init writes the smallest one; this is it with more of what a project can have:

{
  "argv": ["claude"],
  "env": {},
  "port": 4317,
  "user": { "name": "Your Name" },
  "collections": {
    "drafts": { "label": "Drafts", "description": "Prompts kept for later: each starts a new session or is typed into a worker, then is deleted." },
    "reviews": { "label": "Reviews", "description": "One review thread per checkout, written only with `tower note`: not a place for write-ups." },
    "policies": { "label": "Policies", "description": "Standing work the tower starts on a schedule: one markdown file each, a # Title, a json header, then the prompt. `tower policies` lists them." }
  },
  "projects": {
    "my-app": {
      "name": "my-app",
      "hub": "/abs/path/to/my-app",
      "repos": ["/abs/path/to/my-app-api"],
      "color": "#c792ea",
      "shelf": [{ "label": "Notes", "md": "notes/*.md" }],
      "collections": {
        "games": { "label": "Games", "description": "Games played in Tower 3D's arcade: one self-contained .html file each, kept with `tower keep games <file>.html`." }
      }
    }
  }
}

A project's sessions start in its hub; its repos are granted as file access only, so their own CLAUDE.md and skills stay out. The shelf keeps pages beside its sessions. collections are sets of files the project keeps for later, every project's at the top level and a project's own under it; each description says what its collection is for, to the user and to every worker. Three ids drive features and tower init declares them: reviews holds the review threads, policies the work the tower starts on a schedule (without it nothing runs on one), and the renderers that ship read drafts as prompts waiting for a worker. port is where the tower serves (http://127.0.0.1:<port>): set another when 4317 is taken, then tower down and tower up. Every key the config takes is in docs/config.md; tower config check checks an edit, each problem at its key.

Develop

npm run typecheck
npm test        # replays recorded session logs (test/fixtures) through the bridge, checks Tower 3D's models

• AGENTS.md: architecture, data and code rules.
• kb/: the knowledge base, a working theory of the system (systems, flows, decisions, terms) backed by refs into the code. Render it with node .claude/skills/kb/tool/kb.mjs render and open kb/dist/tower.html.

License

MIT (LICENSE). Tower 3D's models and characters are from Kay Lousberg's KayKit packs (CC0); the fonts and libraries it ships with keep their own licenses: THIRD_PARTY.md.