Launch Claude Code sessions on a remote Linux machine and drive them from the Claude mobile app or claude.ai/code — code, notes, research, inbox, anywhere.
Claude Launchpad is a minimalist web UI that starts claude remote-control sessions on a server you own, so you can pilot them from the official Claude mobile/web app without ever opening a terminal.
Claude Launchpad is a thin wrapper. It runs a small web UI on your server whose only job is to start claude remote-control sessions you can then drive from the Claude mobile app. That's it — no terminal, no AI magic of its own.
The value is in what the combination unlocks:
- Claude Code on a machine you own — full shell, filesystem, git, your
CLAUDE.mdconventions, your MCP servers, your files. Nothing sandboxed. - Always reachable from the Claude mobile app — no SSH, no laptop. You open a browser tab on your phone, pick a directory, tap Launch. The session shows up in the app's session picker.
- A knowledge base you control — typically a Markdown vault versioned with Git. Because Claude Code can read and write into this vault, the assistant's own context (
CLAUDE.md, skills,.mcp.json, notes) evolves over time. Each session inherits what the previous one learned or refined.
The last point is the one people tend to miss. If your operating knowledge lives in a Git-versioned vault, a Claude Code session can update its own working files: append a new rule to a CLAUDE.md, add a skill, install an MCP server, write a note in the right folder. Next time you launch a session in the same directory, that change is just there. The assistant grows with use instead of forgetting at every new conversation.
Launchpad is what makes that loop reachable from your pocket.
This project makes sense if most of the following apply:
- You already run (or want to run) Claude Code on a server you control
- You've built or are willing to build a Markdown knowledge base versioned with Git, where procedures and references live as files
- You've used Claude.ai with connectors (Gmail, Calendar, Drive, Notion…) and hit its limits: static Project uploads, no sub-agents, no hooks, no way for the assistant to modify its own configuration
If you're happy with Claude.ai + Notion/Drive connectors for general assistant tasks, you probably don't need Launchpad. Pick it up when you want the Claude Code machinery — not just a chat with tools — reachable from your phone.
When a claude remote-control session is driven from the official Claude app, the app's connectors (Gmail, Calendar, Drive, Notion, etc.) stay available to the session. You don't trade them for Claude Code — you add to them:
- Local MCP servers on your server: filesystem, shell, git, plus any community or homemade MCP that fits your workflow
- MCPs Claude Code builds for you on demand — if a small integration keeps coming up, you can ask the session to write it as a local MCP and wire it into
.mcp.json. Next session, it's just there.
The mental model isn't "Claude.ai or Launchpad". It's the app's connectors, plus your server's MCPs, plus an assistant that can extend its own toolbox over time.
Once a Claude Code session is up on your server, the official Claude app can drive it through anything that session has access to — your code, your notes, and whatever MCP servers you've wired in. A few concrete scenarios people run:
- 📓 "Add to my project X journal: client just validated the migration plan" — or "remind me what we agreed on Saferpay pricing last month". Claude writes to the right spot in your Obsidian vault (commit + push), or reads across notes to answer.
- 💻 "Add password-reset to my app with tests and open the PR" — dictated from a train. Your server already has the deps, DB access, and MCPs wired up; Claude works, pushes, opens the PR.
- 📚 "Survey the current open-source vector DBs, comparison format" — Claude researches the web, drops a sourced note in the right folder of your vault.
- 🤖 "Triage this morning's inbox by priority, draft 3 replies, block 30 min Monday for the two prospects" — via email and calendar MCP servers, one prompt.
Claude Launchpad is the start button. The actual work is done by Claude Code, your MCP servers, and your own data — none of which ship with this project. See Use cases in detail at the bottom for prompts and setup per scenario.
| Tool | Web UI | Embedded terminal | Purpose |
|---|---|---|---|
| Claude Launchpad | ✅ mobile-first | ❌ (by design) | Launch/kill sessions for the Claude mobile app to pick up |
| Codeman | ✅ | ✅ xterm.js | Full web terminal with 20 parallel sessions |
| 247-claude-code-remote | ✅ | ✅ | Mobile terminal via Cloudflare Tunnel |
| claudecodeui | ✅ | ✅ | Web GUI replacement for the Claude CLI |
If you want to type into a terminal from your phone, pick one of the others. If you want to start sessions that the official Claude app then takes over, you're in the right place.
- 📱 Mobile-first responsive UI (tabs on small screens, two-column on desktop)
- 📂 Browse any subdirectory under a configurable root
- 🚀 Launch
claude --remote-controlin a fresh tmux session - 👀 Live tmux pane output viewer for debugging
- ☠️ One-click kill for any session
- 🔐 Stateless header-based auth
On the remote server:
- Node.js 22+ (installed via nvm is fine)
- tmux —
apt install tmux/brew install tmux - Claude Code — installed and signed in on the server
- A reachable port (or reverse-proxy) for the web UI
git clone https://github.com/<your-user>/claude-launchpad.git
cd claude-launchpad
npm install
cp .env.example .env
# Edit .env — at minimum set AUTH_PASSWORD, CLAUDE_BIN, ROOT_DIR
npm run build # compiles the React client into server/public/
npm start # serves everything from ExpressVisit http://<your-server>:3456.
npm run devStarts the Express API on :3456 and the Vite dev server on :5173 (Vite proxies /api to Express). Hot reload for both.
All config lives in .env (see .env.example):
| Variable | Purpose |
|---|---|
PORT |
Port the server listens on (default 3456) |
AUTH_USERNAME |
Username for the login screen |
AUTH_PASSWORD |
Password for the login screen — change this! |
CLAUDE_BIN |
Absolute path to the claude binary (tmux panes don't inherit nvm's shell init) |
ROOT_DIR |
Base directory users are allowed to browse (e.g. /root, /home/youruser, /Users/youruser) |
The app itself should survive SSH disconnects. Easiest approach — wrap it in tmux:
tmux new -s launchpad
npm start
# Detach: Ctrl+B then DOr use a systemd unit, pm2, Docker, etc. Any process supervisor works.
⚠️ systemd + MCP servers: systemd units don't inherit your login shell'sPATH. If your projects use.mcp.jsonwith servers launched viauv,pipx, or anything in~/.local/bin, the MCP servers will fail to spawn silently. Add the binary directories to your unit'sEnvironment="PATH=...". See TROUBLESHOOTING.md for details.
The built-in auth is a minimal shared-secret check over plaintext headers. Before exposing Launchpad to the public internet you must either:
- Put it behind HTTPS with a reverse proxy (nginx, Caddy, Traefik), or
- Keep it on a private network (Tailscale, WireGuard, ZeroTier), or
- Bind it to localhost and reach it via SSH port-forwarding
Opening port 3456 directly without TLS exposes your credentials in cleartext. Don't.
Full-stack TypeScript, single package.json. In production, the React build is served statically by the Express API — one process, one port.
server/
├── index.ts # Express entry point
├── middleware/auth.ts # x-username / x-password header check
├── routes/
│ ├── browse.ts # GET /api/browse?path=
│ └── sessions.ts # GET/POST /api/sessions{,/start,/kill,/output/:name}
└── utils/tmux.ts # All tmux interactions (ls, new-session, send-keys, kill, capture-pane)
client/src/
├── App.tsx # Auth + tab state
├── components/ # FileBrowser, SessionList, AuthScreen, LaunchBar, …
├── hooks/ # useBrowse, useSessions (5s polling)
└── api.ts # All fetch calls, credentials injected as headers
tmux is the session-persistence backend today, but the abstraction is small (all of server/utils/tmux.ts) — swapping to systemd user units or another process manager is a focused change.
See ROADMAP.md for planned features that aren't implemented yet and the upstream work they're waiting on.
See TROUBLESHOOTING.md for known issues, including the "session created but not visible in the Claude app" bug (related to anthropics/claude-code#44805).
Each of these assumes a Claude Code session launched via Claude Launchpad and driven from the Claude mobile app. The heavy lifting is Claude Code + your MCP servers + your own files — Launchpad only starts the session so the mobile app can pick it up.
Prompt (write): "Add to my project X journal: client validated the migration plan, refused option B. Next step: draft the migration risk doc."
Prompt (read): "Remind me what we agreed with Marc on the Saferpay pricing last month."
What happens: Claude opens your Obsidian vault (mounted on the server and kept in sync via Git), finds the right file using the conventions documented in the vault's own CLAUDE.md, appends the new entry in your usual format, commits, pushes. For reads, it greps across notes, cross-references dates, and returns a synthesis with links to the source notes.
Setup: Obsidian vault hosted on the server, synced to/from your laptop via Git. An Obsidian MCP server is optional — for many setups, plain file access is enough since the vault is just Markdown.
Prompt: "Add a password-reset flow to the backend: endpoint, tests, DB migration. Open a PR when done."
What happens: Claude works in the repo checked out on your server, iterates on files, runs your test suite, commits, pushes the branch, opens the pull request. Because everything runs server-side, the session has full access to your usual DB, env vars, and dev dependencies — not a sandboxed cloud with partial tooling.
Setup: the repo cloned on the server, a CLAUDE.md at the project root documenting conventions, any project-specific MCPs (issue tracker, CI, etc.) registered for Claude Code on the server. For authenticated PR creation, a Git host token on the server.
Prompt: "Survey open-source vector databases actively maintained in 2026. Compare pricing, query performance, and ecosystem integrations. Drop the result in my 'Tech watch' folder with sources cited."
What happens: Claude browses the web (via its built-in search/fetch), extracts the comparison data, formats the result according to your vault's note template, and creates a new file in the folder you specified — sources linked at the bottom. You read the note in Obsidian when you open your laptop.
Setup: vault accessible on the server, a templates folder, and vault conventions described in the vault's CLAUDE.md so Claude knows where notes go by topic.
Prompt: "Triage this morning's inbox by priority given my current projects. Draft replies to the three most urgent. Block 30 minutes on Monday morning for the two prospects."
What happens: via an email MCP server, Claude reads incoming messages and ranks them against project context it pulls from your vault. Via a calendar MCP server, it creates the focus block. Drafts are written to your email client's draft folder — you review and hit send when you're ready.
Setup: an email MCP server and a calendar MCP server configured for Claude Code on the server. Optionally, your vault's CLAUDE.md defining what "urgent" means for your current projects.
Issues and PRs welcome. For non-trivial changes, please open an issue first to discuss the approach.