Hacker News

Comments like this show that Claude devs are so disconnected from how Claude or harnesses in general are used in the real world.

Claude Code doesn't even have a basic 'enqueue' prompt feature. Even though Copilot CLI, Codex and many other harnesses have had this for a long time now. And the GitHub feature request for this was closed, by you, referencing a completely unrelated feature.

>2. Permission rules are old hat. Everyone should be using auto mode instead. It is safer and also does not require manually maintaining finicky allow/deny lists.

The fuck we will give free reign to Claude to vibe what's secure and what's not and what it can't do.

I want fully static control over certain folders. Permissions rules should be ABSOLUTELY enforced sandboxing (even without the user bothering with custom sandboxing themselves) on top of any mode, manual or auto.

I want to draw deterministic boundaries around what the agent can do. I don't want a probabilistic approach to security.

My view is that if the agent can decide to do something, nothing stops that thing from being done accidentally, and any attacker that can inject text into its context can do that thing.

I'm not here to be critical, but the hoops you have to jump through to get Claude out of .env is more than it should be. You basically need an agent to write it if it's anything complicated, like, allow .env.example but not .env.*.

Whereas that should probably be default on instead, and this should apply to other known sensitive folders. A simpler system like .agentignore would be even better.

I like auto mode but "the agent supervises itself" is a bad compliance/safety answer on its own.

I would never trust an agent in auto or even manual mode.

Agents should be seen as extremely smart developers that are for sure spies.

You put them in a prison within a prison and give them just what they need to accomplish their work.

> Everyone should be using auto mode instead. It is safer

This is an absolutely crazy statement without also bundling proper sandboxing. Nobody should be using auto mode outside of an environment they'd be happy with an 'everything is approved' mode too.

This is EXACTLY why I never use an agent outside of https://github.com/kstenerud/yoloai

I appreciate that you're trying to make Claude Code safer, but the agent really needs to be a lot more restricted in its reach rather than its actions.

The agent should NOT have ANY access to:

- Your ENV

- Your homedir

- The network at large

- ANY other directory on your system

- No, not even your workdir.

The only safe way to use an agent is COMPLETELY isolated by a container or VM, using git semantics to extract its output.

Boris, love Claude code and similar harnesses. This is a modality problem. Set up a secure mode. The harness should manage the secrets injection at the tool level, and the agent should be sandboxed and never see them. The agent sees the manifest of available tools and are wired up and have enough instruction about how to use and how to set up. Similarly permissions should be scoped to opt in folders.

Auto mode cannot be considered safer than anything because it does not even attempt to guarantee any sort of security. The threat model is not even defined. It cannot be quantified or compared with any other approach other than "full access"

Food for thought - ai agents should not directly have your actual secrets 99% of the time. While Auto mode is useful and good it's not going to be bulletproof. We ought to have something like an agent egress proxy that swaps in real secrets.

Obviously I've not given this enough design thought, but some means of providing an agent stand in secrets that cannot be used in other contexts would be a big improvement for trustability in things like cc.

Saying the answer is auto mode almost feels insulting as a developer. Claude loves showing me the most obscure bash commands where it hides its edits to numerous files and runs who knows what that there's barely a time where I don't have to ask it to use edit mode and to show human-readable bash commands. Using Claude has become a fight in maintaining control over how my codebase works so that I'm not dependent on Claude to do literally anything.

This still presumably happens in auto mode as it asks for sensitive commands (and the default is "always allow," which saves it)

That is some unsavory buck passing. Virtually anyone that didn't ask claude to create the project can leak passwords, with 1,122 known customers that have been impacted. Whether it is standard or not is irrelevant, it is part of existing functionality and entirely foreseeable. I'd expect any company worth the opportunity for trust to clearly own the mistake.

I and other colleagues have been struggling with auto mode refusing perfectly safe commands in our environment, so we frequently find ourselves switching to the other modes to handhold Claude Code into perfectly safe things like triggering deterministic and guardrailed CI/CD pipelines or read-only queries of production data. Auto mode seems overtuned for caution around deployment and production, which is a regression from how useful Claude Code was for operations around June/July. Until that's improved, permission rules are incredibly important to our workflows.

Suggest adding it to ~/.config/git/ignore

and teach Claude to not git add .

While we're at it, maybe we can also discourage the spurious use of -f for rm -- me personal pet peave

GitHub charges an arm and a leg for this service. Before, they would take request to delete committed secrets, now they simply refuse, because they want to force you to buy the overpriced Advanced Security.

Which is odd because my agents are hyper aware of scrubbing. It even caught data from the database migration that wasn’t scrubbed correctly even in a private repo. Dozens of data segments are stored locally and I’m warned when I slip up in commits. Something made mine hyper aware of security.

Offtopic: The new fullscreen renderer is a nice change. It fixes some issues inherent to rewriting terminal history that the non-fullscreen mode relied on. This is a very welcome improvement. Although I should probably switch to the Claude GUI app anyway. It probably has all features from Claude Code by now.

> Permission rules are old hat. Everyone should be using auto mode instead

Boris, this comes off as incredibly tone deaf. I don’t want to trust the machine. Trusting the machine is how we end up here. I want to specify exact, deterministic rules that are always followed.

Isn’t the simple answer shipping a local secret manager with Claude code?

> Everyone should be using auto mode instead. It is safer [...]

This is bullshit.

I'm one of the people who actually reads the commands, and it doesn't always get stuff right. Please don't delude yourself into thinking "auto mode" is some magic that's the right fit for everyone and every situation.

I appreciate you getting communication out in front of this fast.

> "but we are looking into what we can do to prevent this"

I would presume that CC's auto-review of tool-call turns would already solve this >99% of the time, no? From my read, any harness-side deterministic solution here would be saving the user from themselves, which seems like a bad pattern. Somewhat dulling the scalpel in my mind.

> Everyone should be using auto mode instead. It is safer and ...

Okay, sorry, I am out. It's too beautiful a day to have silly arguments.

A bit careless but mostly a bad default. One click shouldn't put passwords in files people commit. Anthropic should fix it.

I guess "you're holding it wrong" is a PR strategy now.

Auto mode should be used by default? Is this the same mode that led to the Anthropic article discussing unintended model actions?

Ref: https://www.anthropic.com/research/investigating-unintended-...

No thanks.

Coding is solved. Bugs not solved yet. Fix incoming

> but we are looking into what we can do to prevent this.

Wait, I'm confused. You said yourself coding was solved, surely all you need to do is ask your AI God to come up with an idea, right?

It doesn’t matter if they should stay local, day 1 security best practices say you don’t write secrets to files, ever - especially without you even knowing!

This is such a typical blame the user response. You realize if I’m a sysadmin managing fleets of machines, this is an actual wake up in a cold sweat nightmare, even if those files never leave disk? In the past it was less a big deal, way bigger now that your machine god will just download packages and libs that have upstream malware that aggressively scans the file system for stuff like this. guess where it’s going to look first?

have more humility. jesus.

> 2. Permission rules are old hat. Everyone should be using auto mode instead. It is safer

Instead of telling people they're holding it wrong, make it safe to be held however they could hold it.

Can we take your responses here to represent your employer's position on this issue?

$19/user/month for secret scrubbing? What a rip off

Use this instead for free https://github.com/awslabs/git-secrets

> Claude Code reads settings from four files, and an organization can also deliver managed settings from the claude.ai console. Each source has a scope: the set of people and projects a setting saved in it applies to, whether that’s only you, everyone in a project, or everyone in your organization.

The linked docs have an unmistakable slop aura, with the extreme overuse of commas that recent models seem to love. I don't blame people for not referring to them (also because, you know, the whole thing with AI is not having to read, think, or understand for yourself)

You guys need a pr team. All the communicate from anthropic seems to screw itself somehow...

Great advice, hope it gets to more people

So ... coding is solved but managing your git repo is not solved?

Wouldn’t it make more sense to put in the user app data directory?

I don’t care how good you guys say auto mode is, I’m not giving your AI full permissions to my machine and the more you try to force AI psychosis onto me the closer I am to moving to something else.

> Permission rules are old hat. Everyone should be using auto mode instead

"you are holding it wrong". No, it's not an excuse. Every mode should work correctly, or should not be selectable.

Yeah Boris, if Dario let's you communicate here, it'd help with credibility if the English level would be perfect, it's "it's an old hat", I dgaf if people will hang me for this, I think I am right. My hill and all that.

And to recommend auto made to devs is absolutely crazy.

Have a nice day

> .claude/settings.local.json is meant to stay local. This is not a file you should check into source control.

Then don't put it in the fucking tree, you idiots.

No, .gitignore is obviously not enough.

Can secret scanning be enabled by default?

> Permission rules are old hat. Everyone should be using auto mode instead. It is safer and also does not require manually maintaining finicky allow/deny lists. Auto mode is enabled by default and is included for free in all plans.

More and more it seems we are being prescribed a particular way to use Claude Code: move fast, break things, do not look at the edits, etc. Basically, Claude Code is designed for vibe-coding.

I hate this, and I suspect a lot of devs do too. I use the TUI, and believe it or not, I like to review every edit or change before Claude makes it. I used to allow auto mode and don't ask again sometimes in the past, but now almost never do. The number of incredibly nonsensical things I catch Claude trying to do sometime just reinforced my commitment to this way of working.

So now this idea that permissions are old hat and auto mode is the way to go rubs me the wrong way, very much. And here are a litany of other ways Claude Code TUI is making it hard for me to work:

1. Scroll-back glitches, too numerous to enumerate. Suffice it to say I rely on it a lot, to refer back to something the agent said before, to review the general progression of the session, etc, etc. And it barely works now: missing/overwritten conversation text, messages that have inexplicably disappeared; even sometimes the agent own last response is garbled or hidden or overwritten by some previous message that keeps floating on top.

2. I use iTerm2 on macOS, and frequently use split panes. Whenever change the width of a pane, Claude Code messes up the conversation text so that is often unreadable, and nothing I do will restore it.

3. As other sibling comments have noted, the current preference of Claude to use incomprehensible scripts for editing files is off-putting and a hindrance to being in control of my work. I have resorted to using the permissions setting to ban it from using Go, Perl, Python, and sed (for in pace editing), etc, to cope with this.

4. Even basic text editing is messed up in Claude Code TUI. I used to be able to navigate around lines effectively by using up/down keys; this was removed, which has significantly impacted by work. I cannot disable copying on selection, which I don;t want, because if I disable it, the copying does not work at all, etc

At this point, due to all the impediments Claude Code places to my style of working, the only reasonable conclusion I can reach is: I am supposed to be vibe coding, letting the agents loose to vomit out massive amounts of slop. But if vibe coding of the Claude Code TUI itself is producing such garbage, why should anyone be convinced that it is a good thing?

I will never let Claude Code loose to do its thing; I will not surrender my control to it, no matter how much many times I hear I no longer need to look at code.

Man. I'd prefer talking to Claude. He wrote the code.

Please, just go borrow from this: https://github.com/hackafterdark/phosphor

I don't mind. I put it out there for everyone to borrow ideas from it. There's documentation too.

While you're at it, please bring Claude Code up to par in Windows with the OS level sandboxing (Job Objects, AppContainer).

There are actually many things you can (and I think should) be doing.

That's the chain, yes. The part people don't expect: the file is created inside the project, and Claude Code only adds it to your global git ignore, not the repo's .gitignore. So a fresh clone or a second machine commits it like any other file. In 539 of the 1,105 repos we traced, a commit co-authored by Claude itself changed the file.

> At the same time, I want them to take away the tedium of a bunch of tasks I'm required to do, and it sucks to have to micromanage them.

Consider reframing. Is the problem really that the task is tedious? Or that it's required? Maybe you should be leaning more on deterministic automations (which the LLM can help set up) rather than LLM-powered ones.

I'm skeptical of how "super paranoid" you actually are. This doesn't sound super paranoid.

For instance: that's a ton of surface area. Did you have your AI agent decide which endpoint is destructive or did you manually do this?

For instance: has this classification been wrong?

I ask this because I've used a similar thing before and it failed in the ways I've named.

This setup also permits your agent to exfiltrate enormously sensitive data (website gives the example of QuickBooks invoices and Cloudflare config) without your involvement.

If the thing is not worth writing by yourself, then it is probably not worth of reading by any humans.

don't edit Ai garbage - make Ai your editor that points out mistakes instead

Why would you "remember" to edit when you explicitly resorted to AI not to do any of that?

I refuse to use op cli because of the absolutely bunkers security model that’s a wontfix:

https://news.ycombinator.com/item?id=45478553

https://codeberg.org/manchicken/1password-cli-vuln-disclosur...

Risk of exposing a single credential is nothing compared to the risk of exposing everything through op cli’s expected behavior. Has there been any improvement on this?

https://news.ycombinator.com/item?id=50365442

The problem is LLMs marketed as a replacement for professionals (who know something about OpSec among other stuff). Internet is full of stories about apps vibecoded by people without IT background. They would not even understand what’s the problem here, for them it’s all magic.

Mind boggling that supposed professionals in this thread will blame Claude and suggest a 100 different third party tools instead of reviewing code committed to a public repository.

> So, it's not necessarily "public", it's simply in the repository, and whether it's actually public or not depends on the repository settings.

Even then, you might not want every developer in your company to have the password to the production SQL database...

Thanks, fair point. Our 1,122 files are all in public repos. In a private repo, only people with access can read it, but "don't ask again" still writes the password into a project file that gets committed, so it spreads with every clone and fork, and goes public if the repo does.

But the whole point of Claude Code is that software production is a solved problem accessible to anyone.

To be fair, things like AGENTS.md aren't supposed to contain secrets, and are helpful to publish for OSS developers who want agentically-written third-party contributions to follow certain rules.

From TFA:

> Often Claude commits the file itself. In 539 of the 1,105 repos with a real secret that we traced, a commit co-authored by Claude changed the file. Those commits name every recent model, from Sonnet 4.5 to Opus 5.5.

always was

I’ve set a hard rule for my agents to “never add all files, never commit all files, always reference the specific files you are adding or committing”

They violate it so regularly that my “git” command is now a wrapper, when the agent fucks up and tries to add/commit-all anyway, it now gets a nastygram error chiding it for not following instructions.

Claude did the research too, Opus 5.5 specifically. It took the findings surprisingly well.

There are a lot of legitimate reasons to have a public github/gitlab/whatever account that is not self hosted.

There’s a reason why private and public repo exists.

it's 2026. surely you're aware of ci/cd? static page hosting? package hosting? the many other services that github offers beyond hosted git?

> I still don't understand why people are using GitHub for their vibecoded projects.

For all the same reasons they used it pre-LLM for hand-written toy projects.

To post on linkedin and to brag about all your projects and active github account when applying to jobs.

You think people that vibe code have a NAS?

Or git-crypt, which has been around for over a decade: https://github.com/agwa/git-crypt

Devs have been leaking secrets in public repos a long time before now. Nothing new here, except there are now more with dev power, which statistically means more leakage.

That’s ridiculously overblown rhetoric. Claude Code didn’t publish these secrets, the users did by committing their Claude Code settings to public repos.

Same thing could/would happen with an open source harness.