Ashnazg Enterprises LLCBasic Installation of Claude Code's JS CLI
yarn global add @anthropic-ai/claude-code- (or
npm install -g @anthropic-ai/claude-codeif you're still on npm.) - (see https://docs.anthropic.com/en/docs/claude-code/overview)
- (or
Isolating Claude from your artifact storage and prod systems
- I'm using Claude Code to write code on my dev env. Til now I've been running it with all of my own permissions, but after the replit disaster I've taken to isolating my Claude Code usage. Normally, I've qa and prod services for a bunch of minimal-server-load projects all running on a tiny EC2, using nginx's virtual hosting to keep them straight, and an admin-keyed dev session can push anything up, but all Claude Code is going on a new EC2. (Using a t4g.large to give claude the recommended RAM elbow room.)
- Now isolation is as simple as having two ssh sessions: one with
ssh -aso that claude can't tunnel forward into my ssh://prod services, and one normal ssh connection to the claude-server so versioning and deploying as easy as a git push.
Experiements along the way
- I first tried having my admin-enabled username handle the prod/git work. So I'd run claude while sshing into claude@claudevm (with key-forwarding turned off at the laptop and the bastion between these two points) while sshing into a separate admin. This worked, but I had to run "sudo chown -R claude:devs $claudecode_dir" after most actions, and the risk vs productivity factors said this wasn't really paying for itself.
- So a slightly less paranoid setup was to use the same username for both windows, but have key-forwarding off on claude-code and on for my manual-work window. (If claude was an attacker, this would be an exploitable gap, but the risk surface I'm tackling here is claude doing generally-DevOps things in a disasterous way, not sliding userspace shunts into our now-shared workfolder. Much like how death by asteroid is about fiery/crushing instant death and not that an asteroid could hit just right and sneak allergens into my next sandwich.)
- That worked, but I simplified my method of blocking key-forwarding so that I could simplify my ssh configs everywhere back to where they were yesterday: I use this snippet as an admin to switch temporarily to another username, and the double-bounce involved already breaks the key-forwarding envvars:
sudo su -l claude