FAQ
Everything asked often enough to be worth writing down. If the answer you need is not here, an issue is the right place to ask.
cowork-deck is a free, open-source desktop app for running many Claude Code sessions at once. Each session is a tile holding a real PTY-backed terminal in a project folder, with a coloured rail showing whether it is working, waiting on a decision, finished, or stopped on an error.
Yes. cowork-deck is MIT-licensed, and the whole application is in a public GitHub repository — including the screenshot harness the images on this site were shot with. There is no paid tier and no hosted service.
No. cowork-deck is an independent open-source project and is not affiliated with, endorsed by, or supported by Anthropic. It drives the Claude Code CLI the same way a person at a terminal would.
No. cowork-deck runs the Claude Code already installed on your machine, under whatever plan you already use. The app adds no account, no server, and no cost of its own — it is a window around processes you could start by hand.
Claude Code, logged in. The GitHub CLI is optional and only needed for the account bindings, the boards that read GitHub issues, and the pull request views. If claude is not on your PATH, set COWORK_CLAUDE_PATH; COWORK_GH_PATH does the same for gh.
As many as your machine and your plan allow — the app imposes no limit. cowork-deck itself uses around 100 MB of memory; each session costs what the same claude process would cost in an ordinary terminal.
Prebuilt bundles exist for macOS (Apple silicon and Intel, as .dmg) and Linux (AppImage, .deb and .rpm). Windows builds and runs from source but has no published bundle yet — see building from source.
Not as a published download. Windows is supported in the sense that the app builds and runs there: install Node.js, a Rust toolchain and the Tauri v2 prerequisites, then run npm install and npm run tauri build. Full steps are on the install page.
No. The app is not notarized, because there is no paid Apple Developer account behind the project, so macOS quarantines the download instead of checking a signature. Clear the flag once: xattr -cr /Applications/cowork-deck.app. System Settings → Privacy & Security → Open Anyway does the same thing. More on the install page.
A multiplexer splits panes but does not know what an agent session is. It cannot tell you that one pane finished a turn, that another is blocked on a permission request, what each has spent, or which branch each is on. cowork-deck reads that from Claude Code’s own hooks and shows it as a rail on every tile, plus two counts in the top bar for the only two things that want a person.
Those solve a different problem. Subagents run inside one session under one conversation; worktrees give you separate checkouts but no view over them. cowork-deck is the layer above: many independent top-level sessions, in different projects, under different GitHub accounts, with their state visible at once. It uses worktrees itself when starting a session on an issue or a pull request.
Not yet. Claude Code is the only agent CLI supported today. Reading other CLIs’ session logs is on the roadmap, starting with the activity panel that reports which tools and subagents actually ran.
No. A workspace’s settings hold the account name and nothing else. The token is read from the GitHub CLI’s own keyring at the moment a session starts and handed to the child process through environment variables — GH_TOKEN, GIT_AUTHOR_*, and GIT_SSH_COMMAND where needed.
Yes, and without switching. Each workspace is bound to its own gh account, so sessions in two projects push, open pull requests and sign commits as two different people simultaneously. The app never calls gh auth switch, so your own shell keeps whichever account was active in it. See a GitHub account per workspace.
No. There is no telemetry, no analytics and no account. The optional settings sync writes to a private GitHub repository that you own and create; it is off until you switch it on, and it never carries absolute paths.
In your platform’s ordinary application config directory, as plain files. Boards made of markdown cards live in folders you choose, inside your repository or anywhere else. Uninstalling is deleting the app; nothing is hidden elsewhere.
No. Sessions are children of the app: there is no detached mode, and the scheduler only fires while the window is open. Missed scheduled runs are not lost — each scheduled scenario catches up once on the next launch, once rather than repeatedly.
Yes. Save a prompt as a scenario and attach an hourly, daily or weekly schedule; it fires into a fresh session using stored defaults. The run happens on your machine through your own Claude Code, so there is no cloud agent and no extra bill, and it has your full local context. A scenario whose previous run is still working is skipped rather than stacked.
The terminal is unaffected — you can type, scroll and work normally. The only symptom is a tile whose state label stays on idle. State tracking degrades on its own; nothing else depends on it.
Quitting names the sessions that still have something running and waits for you. What is killed is the whole process session, so a build started inside a shell dies with it rather than outliving the app. Restarting resumes the conversation with claude --resume, and yesterday’s tiles come back on the next launch.
Open a GitHub issue on the repository. Work is tracked there, and decisions worth outliving their issue are written as architecture decision records under docs/adr/.
Tauri v2 with a Rust backend handling PTYs and process management, and a TypeScript frontend using xterm.js with no UI framework at all. Resident memory is around 100 MB.
Not yet. The interface is English-only today by written rule, which is a decision about the source rather than about the person using it. A language switch and translated strings are on the roadmap. Prompts are unaffected: a scenario’s placeholders are matched by letter rather than by ASCII, so a prompt written in any script names its fields in that script.
