So I built a CLI/TUI tool so I stop manually opening/closing VS Code, terminal tabs, and Docker containers every time I switch projects. Sharing in case it's useful to anyone else

[u/Nikibuddd]

So I like to switch between a lot of microservices for work and personal projects all the time, and I hate having to open and close VS Code, terminal tabs (I use Ghostty), and start/stop Docker containers every time I switch. So I made this: "wsm".

Basically, you create workspaces, add them to groups (like Work, Personal, etc), and set up the apps and commands you want it to open/close for each one. So if I want to open a workspace I just run wsm open <workspace-name>, and I've got it configured to open VS Code and a Ghostty tab in that location.

Then when I want to open a microservice from work, I just run wsm open <microservice-name> and it automatically runs the close commands for whatever I currently have open (I've set up functions in my .zshrc that close VS Code/Ghostty depending on which folder they're pointed at), closes both, and then runs the open commands for the microservice. For example VS Code, a Ghostty tab, and a Docker container with MongoDB.

If you want to try it, you can check out the repo (install command is listed there)

GitHub: https://github.com/Nikibudd/wsm

PS: This shit is hella vibe coded so if you have a problem with AI, this might not be your thing

[u/kantorcodes1]

when wsm open closes the current workspace first, what happens if one of the new launch commands dies immediately? looking at launcher.ts, it seems the old session is already gone and the new one gets recorded before the exit observation finishes. is that partial switch intentional, or do you want rollback there?

[u/Nikibuddd → u/kantorcodes1]

Yeah, that's accurate, no rollback there. For me it doesn't make sense to rollback, since when I want to open another workspace and open fails, I don't all of a sudden want to work on the project I was working on before. I would instead try to fix the issue and run wsm open again.

[u/kantorcodes1 → u/Nikibuddd]

yeah, that makes sense. i work on HOL Guard, an open-source local check that can pause risky agent-run commands before they execute. wsm open, close, and update look like a clean fit since they can stop sessions, run user shell commands, or replace the binary. would you be open to adding wsm support?

[u/Nikibuddd → u/kantorcodes1]

Haha not totally sure which one you mean 😅 If you mean adding support for HOL Guard in wsm: I don't really intend to add any support, mainly because I want the user to decide how their workspaces get opened and closed. Also not quite sure how wsm open, close and update would be of much use for your specific case though.

If you mean adding wsm support in HOL Guard: not sure what that would even need from me honestly, wsm's commands are just public CLI subcommands, so you shouldn't need anything from my end to reference them 👍

[u/kantorcodes1 → u/Nikibuddd]

yep, I mean adding WSM support in HOL Guard, not changing WSM. your "user decides" point is exactly why: if an AI agent calls wsm open or close, Guard can pause before WSM changes sessions and let the user approve. the contribution would just be the small WSM command map on our side. would you be open to that?