Claudespace

After testing a few different coding agents over the last few months, we found Claude Code to be the best (by far). A few reasons why it’s good are:
- Claude is the best foundational model for coding.
- The unlimited usage period was sweet while it lasted. I’d love to meet the legend who spent $10K+ on Claude per week.
- Its CLI-first interface aligns with how developers think and work. It’s direct, minimal, and integrates easily with existing tools.
- Its responses and reasoning traces are concise and to the point—without the fluff you get from other agents that tend to over explain even the most trivial details.
- Git is how developers collaborate. We treat Claude Code as developer, and its CLI naturally integrates with established workflows.
How we use Claude Code
We run Claude Code directly on our laptops rather than through a hosted interface. For our small team, the overhead of replicating our development environment in the cloud and keeping it in sync isn't worth the headache.
Initially, we used Claude Code on our main local checkout, but this prevented us from working on our own tasks while running Claude Code. We solved this by keeping two local copies of our repo (one dedicated to Claude Code) allowing it to work independently without interfering with our development. Though, working with multiple checkouts introduced its own headaches: bouncing between editor windows, keeping track of which was which, and managing Git state across both added unnecessary friction.
However, we soon ran into issues with a shared dev environment, particularly a shared local database. Whenever schema migrations occurred in either repo copy, it inadvertently broke the other copy’s development. Our solution was to create a second docker-compose.yaml file to give Claude Code to give it its own environment. A downside of this was the frustration of switching between Cursor windows when we needed to directly edit Claude Code's work to help it move forward.
Finally, as Claude Code became part of our daily workflows, the single-instance limit started to become bottleneck in our workflow. So we decided to (vibe) code our way out of this.
Introducing Claudespace
We built a lightweight CLI utility called claudespace to manage isolated local workspaces for Claude Code. Here's how it works under the hood:
- It uses git worktrees to create a copy of our repo, which is much faster than doing a full clone.
- It dynamically generates a new
docker-compose.yamlfile that remaps services to available ports. - It automatically updates environment variables in
.envfiles within the workspace to point to the newly assigned service ports. - It provides several quality-of-life commands, including opening Cursor with the workspace preloaded, auto-writing commit messages, and pushing/pulling changes to GitHub.
A typical workflow now looks like:
claudespace create feat-xto create a new isolated workspaceclaudespace attach feat-xto launch Claude Code in the workspaceclaudespace cursor feat-xto open the workspace in Cursor when we need to edit files to help Claude Code out.claudespace push feat-xto push the changes to GitHub
Claudespace isn't designed to be a one-size-fits-all tool. It just works well for our workflow. Though chances are your development process looks pretty similar or can be adapted to how Claudespace does things. Feel free to fork the repo and tweak it to fit your needs. PRs are welcome as well!
Useful tips
A few things to help you compound with Claude Code:
- Use
.claude/settings.jsonto give Claude Code autonomy to take actions. People have varying comfort levels regarding AI autonomy, but we found the default settings too limiting. - Actively maintain
CLAUDE.md. Whenever you notice Claude Code making the same mistake repeatedly, document it to prevent recurrence. Keep all your technical docs in your repo rather than a CMS, and use@path/to/importto link to them. - Use subagents to automate repeated workflows, e.g. we have subagents to manage schema migrations, codegen, adding new API endpoints, etc.