Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Code 2.0

npmjs.com

Post reply on HN
Print view View original

411–420 of 431 posts

Re: Claude Code 2.0

#411

Post by versteegen »

simonw wrote: post #379
wiesbadener wrote: post #357

Earlier quoted context omitted.

Hi Simon, I share your worries on this topic. I saw you experiment a lot with python. Do you have a python-focused sandboxed devcontainer setup for Claude Code / Codex you want to share? Or even a full stack setup? Claude's devcontainer setup ( https://github.com/anthropics/claude-code/tree/main/.devcont... ) is focused on JS with npm.

I've been trying out GitHub Codespaces as a sandbox, which works pretty well. I wrote a bit about that in a new post this morning, but I'm still looking for an ideal solution: https://simonwillison.net/2025/Sep/30/designing-agentic-loop...

Using a container or a VM is still friction compared to just working on your files directly using a separate user account to prevent unsophisticated bad behaviour. I:

-create a separate linux user, put it in an 'appshare' group, set its umask to 002 (default rwxrwxr.x)

-optional: setup some symlinks from its home dir to mine such as various ~/.config/... so it can use my installed packages and opencode config, etc. I have the option to give it limited write access with chgrp to appshare and chmod g+w (e.g. julia's cache)

-optional: setup firewall rules

-if it only needs read-only access to my git history it can work in a git worktree. I can then make git commits with my user account from the worktree. Or I can chgrp/chown my main working copy. Otherwise it needs a separate checkout

Re: Claude Code 2.0

#412

Post by brookst »

simonw wrote: post #338
brookst wrote: post #317

Earlier quoted context omitted.

Dangerous how? Claude code literally asks before running any command. I suppose they’re dangerous in the same way any terminal shell is dangerous, but it seems a bit of a moral panic. All tools can be dangerous if misused.

Many people (myself included) run them in YOLO mode with approvals turned off, because it's massively more productive. And that's despite me understanding how unsafe that is more than most! Even with approvals humans will fall victim to dialog fatigue, where they'll click approve on everything without reading it too closely.

Well sure, it’s like riding a motorcycle without a helmet: while it is true that motorcycles are dangerous, it’s hardly fair to characterize their danger based on the no-helmet risks.

Re: Claude Code 2.0

#413

Post by ode »

flyinglizard wrote: post #170
aitchnyu wrote: post #34

Tangential, did anybody get FOMO about Aider and found a much better tool?

Still loyal to aider. It just fits my style better, as a very fine tool. I have my workflow and scripts around it, switch freely between gpt-5/sonnet (a bit of gemini-2.5-pro too) and enjoying life. I wish it was maintained by a larger team though. It has a single maintainer and they seem to be backlogged or working on other stuff. If there was an aider fork that ran forward with capabilities I'd happily switch. That…

There is https://github.com/dwash96/aider-ce

'This project aims to be compatible with upstream Aider, but with priority commits merged in and with some opportunistic bug fixes and optimizations'

Re: Claude Code 2.0

#414

Post by ACCount37 »

IMTDb wrote: post #372
ACCount37 wrote: post #310

Earlier quoted context omitted.

That's like saying "humans are inherently safe because you can throw them in a jail forever and then there's nothing they can do". But are all humans in jails? No, the practical reason being that it limits their usefulness. Humans like it better when other humans are useful. The same holds for AI agents. The ship has sailed: no one is going to put every single AI agent in jail. The "inherent safety" of LLMs comes onl…

Humans are not inherently safe; there is very little you can do to prevent a human with a hammer to kill another one. In fact what you usually do with these humans is to put them in jail because they have no direct ability to hurt anyone. LLM are in jail: an LLM outputting {"type": "function", "function": {"name": "execute_bash", "parameters": {"command": "sudo rm -rf /"}}} isn't unsafe. The unsafe part is the scaffo…

That's just plain wrong.

For scaffolding to be "safe", you basically need that scaffolding to know exactly what the LLM is being used for, and outsmart it at every turn if it misbehaves. That's impractical-to-impossible. There are tasks that need access for legitimate reasons - like human tasks that need hammer access - and the same access can always be used for illegitimate reasons.

It's like trying to engineer a hammer that can't be used to bludgeon someone to death. Good fucking luck.

Re: Claude Code 2.0

#415

Post by johanneskanybal »

saberience wrote: post #308
simonw wrote: post #49

Something I realized about this category of tool (I call them "terminal agents" but that already doesn't work now there's an official VS Code extension for this - maybe just "coding agents" instead) is that they're actually an interesting form of general agent . Claude Code, Codex CLI etc can effectively do anything that a human could do by typing commands into a computer. They're incredibly dangerous to use if you d…

Incredibly dangerous to use? Seems like a wild exaggeration. I’ve been using Claude code since launch, must have used it for 1000 hours or more by now, and it’s never done anything I didn’t want it to do. Why would I run it in a sandbox? It writes code for me and occasionally runs a build and tests. I’m not sure why you’re so fixated on the “danger”, when you use these things all the time you end up realizing that th…

So far it's screwed up my wifi and directed me through malicious link's I've blindly followed even if I take full responsibility ofc. And that's from less than 80h usage just on my home computer.

Re: Claude Code 2.0

#416

Post by fragmede »

ed_mercer wrote: post #175
freedomben wrote: post #152

Earlier quoted context omitted.

That is nice, but it makes me wonder how little people actually know and use git nowadays. This is after all, something git really shines at. Still good to see! (It's not like I can't still just use git for that, which I fully intend to do)

If you're building a feature, you don’t want to commit every single line of code. Instead, you commit complete chunks of work. That’s why the ability to go back with Esc-Esc and revert code changes when Claude goes off the rails is a very welcome improvement.

Ugh, no. Git is a distributed vcs. Changes in git stay local unless and until you push them to a server, and then furthermore, point someone else at your changes for review. (Formal PR or otherwise.)

Your tools should work for you, and git is no exception. Commit early and commit often. Before you (or an LLM) go on a jaunt through the code, changing whatever, commit the wip to git as you go along. That way, if something goes awry, it's an easy git reset HEAD^ to go backwards just a little bit and undo your changes.

Later on, when it's time to share your work, git rebase -i main (or wherever your branching off point was). This will bring up your editor with a list of commits. Reorder them to make more sense, and then also merge commits together by changing the first word on the line to be "fixup". exit your editor and git will rewrite history for outside consumption. Then you can push and ask someone else to review your commits, which hopefully is now a series of readable smaller commits and not one giant commit that does everything, because those suck to review.

Re: Claude Code 2.0

#417

Post by [deleted] »

visarga wrote: post #230
simonw wrote: post #49

Something I realized about this category of tool (I call them "terminal agents" but that already doesn't work now there's an official VS Code extension for this - maybe just "coding agents" instead) is that they're actually an interesting form of general agent . Claude Code, Codex CLI etc can effectively do anything that a human could do by typing commands into a computer. They're incredibly dangerous to use if you d…

> Claude Code, Codex CLI etc can effectively do anything that a human could do by typing commands into a computer. They still don't have good integration with the web browser, if you are debugging frontend you need to carry screenshots manually, it cannot inspect the DOM, run snippets of code in the console, etc.

[deleted]

Re: Claude Code 2.0

#418

Post by jama211 »

f311a wrote: post #280
jama211 wrote: post #267

Earlier quoted context omitted.

Ram is cheap, 99.9% of the audience that would use this are running heavy envs on powerful computers. I can totally understand why they write it that way. Better to have faster iteration and alienate 0.1% of serious users than to slow development just to cater to them.

Well, it's not only about RAM. Things like calculating correct diffs take more time too, but it's hidden.

Again, the pro/con ratio pays off.

Re: Claude Code 2.0

#419

Post by johanyc »

numpad0 wrote: post #284

fyi: for chatboxes that may take CJK inputs, you MUST use "shift+enter to send" pattern. There is a reason why most multinational chat/LLM app providers always do that instead of simple enter to send even for single-line chatboxes; because plain enter to send breaks input for CJK users. Specifically, Input Method Editors needed for CJK inputs(esp. for C and J), to convert ambiguous semi-readable forms into proper rea…

On that note, does it affect korean though? It seems they don't need to select characters from the menu. I tried typing random characters here: https://urcook.com/kr.html

Re: Claude Code 2.0

#420

Post by jcgl »

tennox wrote: post #406
jcgl wrote: post #314

Earlier quoted context omitted.

Not specific to LLM stuff, but I've lately been using bubblewrap more and more to isolate bits of software that are somewhat more sketchy (NPM stuff, binaries downloaded from GitHub, honestly most things not distro-packaged). It was a little rocky start out with, but it is nice knowing that a random binary can't snoop on and exfiltrate e.g. my shell history.

You might might my (alpha-level) attempt at this: https://gitlab.com/txlab/ai/sandcastle

Looks like it's probably neat, but is kinda inverse from what I myself want. I want:

- something general-purpose (not specific to LLMS (I myself don't use agents--just duck.ai when I want to ask an LLM a question)) - something focused on sandboxing (bells and whistles like git and nix integration sound like things I'd want to use orthogonal tools for)

Post reply on HN