The problem
I wanted to try a customization pack from my friend/cursor mentor @kleosr (rules, hooks, skills, packages and theme, go check it out, it’s cool), but without touching my production Cursor.
I thought about creating another Debian user. That felt overkill just for a lab. I also looked at Profiles / --user-data-dir: they help, but on Linux they don’t fully cover things like ~/.cursor (agents, skills, MCP) or global installs such as npm -g.
The idea: cursor-env
A CLI/TUI (Go + Bubbletea) to create, list, launch, and delete isolated Cursor environments.
Each environment gets its own HOME under:
~/.local/share/cursor-env/envs/<slug>/home
Launching does more than swap HOME. It also sandboxes:
XDG_*(config / data / cache / state)NPM_CONFIG_PREFIX→home/.npm-global(sonpm -gdoes not write into your real~/.local)CARGO_HOME,GOPATH,GOBIN- Sanitized
PATH: no host~/.local/bin, only system paths + sandbox bins
That way you can split workspaces: production, research, rules/MCP lab, etc., without path collisions.
How to use it
go build -o cursor-env ./cmd/cursor-env
./cursor-env
↑/↓/j/k— navigateEnter— launch Cursor in that environmentn— create (name + focus)d— deleteq— quit
Repo: GitHub - jseramn/cursor-env · GitHub
Architecture diagram
What I’d love to hear
Opinions, feedback, edge cases, feature ideas… is this useful to anyone else? How do you isolate “dirty” experimental profiles without risking your production setup?
About me
I’m Jose. I’ve been using Cursor almost non-stop for 30+ days (production + experiments). I barely use the classic IDE: I live in the agent window and read code from the diffs. (Agents Window could use a bit more customization… or am I being too picky? 
)
Thanks for reading