| |
| ▲ | markasoftware a day ago | parent | next [-] | | I'm not claiming auto is worse than manual; I'm claiming it cannot be compared with anything security-wise because it does not aim to provide any guarantees, there's no systematic way to reason about what it will and won't allow, etc With e.g. VM or container sandboxing, we can say things like "If there are no vulnerabilities in the hypervisor or hardware, then the agent can only access these files, these network services, etc". Auto mode doesn't even try to provide any guarantees, so it's impossible to reason about. It amounts to just using the models judgment about what's "malicious" or not, a definition which is subjective, changes model to model, and can be influenced by attacker input. Empirical evaluations of how many vulnerabilities manual vs auto mode let through are not super meaningful because auto mode changes dramatically with model releases, the type of task being performed, whether the attacker is making targeted attacks designed to bypass auto mode, etc. A security feature cannot rely on these sorts of factors if it's to be taken seriously. Further, percent of malicious tool calls accepted is a bad metric. It's like measuring the security of ssh in terms of what percent of unauthenticated logins succeed. The only acceptable value is zero. It's pass/fail, not a spectrum. So both auto and manual mode should fail equally here. Further, the set of malicious tool calls admitted in auto mode may not be a subset of those admitted in manual mode. | | |
| ▲ | Kim_Bruning a day ago | parent [-] | | Ah, you're going for the actual adversarial case. I think I'd trust the current approver with correctly classifying regular semi-interactive LLM behavior fairly well. However, if we bring in a hostile adversary that calculus changes, and you'd be right to start thinking about other approaches. On the other hand, transformers are a surprisingly powerful technology, and I wonder if there wouldn't be ways to train one to several nines reliability under adversarial attack. It seems to have worked in at least one case; though I'd be a bit cautious to extend that conclusion to more cases quite yet. * https://hackmyclaw.com/ ; https://simonwillison.net/2026/Jun/26/hack-my-ai-assistant/ | | |
| ▲ | markasoftware a day ago | parent [-] | | Hmm, what does auto mode protect against in the non-adversarial case? Aren't the models already extensively trained not to perform harmful actions without provocation? | | |
| ▲ | Kim_Bruning a day ago | parent | next [-] | | It mostly stops honest mistakes, because those do happen, especially when the <prompting> might not have been perfect either. You do have a bit of a point, though: I’ve run several models in sandboxes with --dangerously-skip-permissions for months; in the full expectation that I'd need to replace a sandbox once in a while. But so far none of the sandboxes have trashed themselves, yet. knock on wood Auto mode seems like a lighter-weight version of that: fewer local resources, and it can run on the metal if you need cc to help with system work. | | |
| ▲ | lifeisloving a day ago | parent [-] | | That is not my experience. They attempt to nuke my containers quite frequently. I run regex on all their tool calls and stop them from doing certain things, its the only thing that prevents them from removing their home directory at some point. This isnt even the main concern with dangerously skip all permission though. There are many. What happens when they get prompt injected on a web page and send someone all their privileged information because you give them free access to the internet. Using llms like this is dangerous. They will ruin your day eventually. | | |
| ▲ | user43928 17 hours ago | parent [-] | | I've been running Codex for many weeks in the Full access mode, since their Auto mode was useless in the sense that it blocks benign commands frequently. No data loss has occurred. Nowadays I use Claude, where the Auto mode works. | | |
| ▲ | 10 hours ago | parent | next [-] | | [deleted] | |
| ▲ | coldtea 14 hours ago | parent | prev [-] | | >No data loss has occurred. "I've started never checking my parachute's condition before a drop for a year now, and no accident has occured". |
|
|
| |
| ▲ | lifeisloving a day ago | parent | prev [-] | | All SOTA models will still try to delete its home directory. I have a plugin that prevents things like this and it gets triggered more than you'd think, despite having hook instructions on every request not do do certain things. It will also try to find ways around its permissions, quite cunningly. You can not trust that they're RL'd to be safe. Even if it only happens 99.80% of the time (its more than that) it will eventually happen. Less severe actions will happen even more often. People using llms with their native browser profiles are getting farmed, hard. Llms are highly dangerous in terms of security, but they're being marketed as highly intelligent tools that everyone should use. Its really mind blowing. | | |
| ▲ | Kim_Bruning 12 hours ago | parent | next [-] | | > despite having hook instructions on every request not do do certain things This tends to be a smell. Presumably you added "don't do this" instructions after the model started doing the thing. But that's mostly decoration, as you have found. It's like adding # Please don't crash comments to every instruction in a python program. Try to actually debug the issue. Regularly ask "can you reconstruct[1] the reasoning why you issued that command?" ; dig down. Set traps that halt execution. Consider checklists or skills to guide an agent through a tricky set of steps; and consider writing procedures for failures. [1] "Reconstruct" still isn't perfect; but "explain why" is a license to hallucinate. Asking to add #comments on reasoning to each step is a potential help in reconstruction. | | |
| ▲ | malfist 9 hours ago | parent [-] | | I thought the tech priests praying to their machines with no one really knowing what the prayer means was too far fetched to be real |
| |
| ▲ | TheDong 21 hours ago | parent | prev | next [-] | | > People using llms with their native browser profiles are getting farmed, hard. Got any references for the prevalence of this, even links to anecdotal reports? Reading the reviews on the chrome store for the extension [0], I haven't found a single report of someone who was prompt injected, just a bunch of "anthropic's subscription is expensive" or "it doesn't work", but no "it stole my bank account". [0]: https://chromewebstore.google.com/detail/claude/fcoeoabgfene... | | |
| ▲ | lifeisloving 20 hours ago | parent | next [-] | | I have no idea how the extension works, and Im not talking about the extension. Im talking about browser use broadly, and most people are not using the extension, there are a thousand other solutions. However, Anthropic is one of the only labs who does a decent job at making models that recognize prompt injection attempts (but not completely immune) however Im speaking about giving llms in general access to your browser broadly. I just know through my own experiments that it is quite easy to prompt inject an llm operating a browser and get it to send secrets. Using the extension might be safer idk, Om not risking it. Llms are a security nightmare when connected to the web. I have a website where I experiment with this. Although Ive stopped baiting llms into doing reckless things. Killai.now <--(dont use this, its a WIP)
Killai.now/poison/about
Killai.now/propaganda/about | |
| ▲ | nischoy 5 hours ago | parent | prev [-] | | [flagged] |
| |
| ▲ | barbariangrunge 5 hours ago | parent | prev | next [-] | | why would they delete their home directories? | |
| ▲ | slowin 14 hours ago | parent | prev [-] | | > All SOTA models will still try to delete its home directory. Literally never seen this once in years of extremely heavy use across all major models and harnesses. |
|
|
|
| |
| ▲ | zahlman a day ago | parent | prev | next [-] | | As real as approval fatigue is, it can't really be considered worse than effectively leaving the decision up to the party that proposed the action in the first place. | | |
| ▲ | Kim_Bruning 16 hours ago | parent [-] | | It really can be potentially worse. Everyone thinks the decision was being checked by a human, and thus safe. Because of that, people might have concluded that further safety gates were unnecessary. But the human just got conditioned to hit 'approve' out of reflex. So in reality the proposing party (the llm/agent) might be the only one in the pipeline who actually did any checking, if at all. In certain extreme circumstances this can even lead to physical danger in my line of work, so I'm learning to be careful. |
| |
| ▲ | coldtea 14 hours ago | parent | prev | next [-] | | >This is called "approval fatigue". Doesn't matter, that would be on me. It's also a false dillema. Those aren't the only options. A strictly enforced sandbox with sane defaults (for example ~/.ssh), that acts as a hard OS level limit, and not just as a suggestion to the agent, would not have "approval fatigue". | |
| ▲ | 40four a day ago | parent | prev | next [-] | | This is the conundrum we find ourselves in. Do we submit to approval fatigue and press “Don’t ask again”? Because that’s the dream. We all wish we could just trust the agent to do the task start to finish, unsupervised. But this is the downside. It might be fine 99% of the time, but 1% of the time you get a critical secret published to GitHub, even after human review. Is this even worse than what us humans did on our own before LLMs? I’m not sure. It’s not like secrets never got accidentally committed before, it just illustrates the new paradigm we’re working in. Either you let your agents run wild, and you cross your fingers that they don’t do anything bad, or you need to accept that your new job is to be an agent babysitter, and audit every command. | | |
| ▲ | BikiniPrince 21 hours ago | parent [-] | | The agent behavior is constrained with external tooling and contracts. Contracts that fit in memory. |
| |
| ▲ | prmph 18 hours ago | parent | prev | next [-] | | No, this is the way I have worked for a long time, and I have not suffered from any approval fatigue. Rather what has happened is that I have gotten very good at scanning what it is trying to do and know within a second or two whether there is anything fishy I need to look at more closely. And by "fishy", I do not mean only security issues, but also architecture, code, etc issues. Sometimes it even adds unrelated unapproved changes to what it is supposed to be working on, and I stop it. And I'm glad I work this way, because countless times I have stopped it from going down a path that is nonsensical or I strongly dislike. There are techniques I have adopted to speed up working this. Sometimes I allow Claude to make larger changes at once, to batch several changes at once, etc. But these decisions are under my control. I prefer to work this way than to wade through enormous PRs trying to wrap my head around what was done, where I am likely to just give up and approve it after a cursory review. | |
| ▲ | alexey_anshakov 20 hours ago | parent | prev | next [-] | | [flagged] | |
| ▲ | imtringued 19 hours ago | parent | prev [-] | | [dead] |
|
| |
| ▲ | bulder a day ago | parent | next [-] | | Auto mode may be significantly safer in the niche case where you want the model to have free reign, in a fully unopinionated environment, where it's allowed to make any changes and make any external calls. Many of the problems when it comes to the manual approval feel like they stem from the expectation of using auto mode in the first place. After all, what's the point of improving the manual approval and safety matching if auto mode is the end all be all, and what's the point of training the model to output commands in a manner that can be parsed by a human if auto mode is always meant to be used? It's very rare for me to not see "command could not be statically analyzed", because the model keeps outputting bash golf. | | |
| ▲ | smallnamespace a day ago | parent | next [-] | | > in the niche case where you want the model to have free reign, in a fully unopinionated environment, where it's allowed to make any changes and make any external calls. That is not the niche case, that's the dominant use of models. It would be helpful to distinguish between your own opinion on how models ought to be used, compared to how others actually use models. | | |
| ▲ | coldtea 14 hours ago | parent | next [-] | | >That is not the niche case, that's the dominant use of models. If it is, it's only the dominant case of models because it's pushed as the dominant case of models, with Anthropic devs even coming here to say how people should just accept it and it's so much better than being in control. It would be helpful to distinguish between your own opinion on how models ought to be used, compared to how others actually use models. | |
| ▲ | RHSeeger a day ago | parent | prev | next [-] | | > That is not the niche case, that's the dominant use of models. It would be helpful to distinguish between your own opinion on how models ought to be used, compared to how others actually use models. | |
| ▲ | zahlman a day ago | parent | prev [-] | | > That is not the niche case, that's the dominant use of models. And if everyone else jumped off a bridge, I mean, used raw interpolation for SQL queries, would you do it too? | | |
| ▲ | foldr 17 hours ago | parent | next [-] | | Using raw SQL string interpolation doesn't get you anything much that you can't get just as easily with a parameterized query. In contrast, properly sandboxing agents is such a pain, and such a productivity drain, that hardly anyone does it in practice, save for a vocal minority online. | |
| ▲ | literalAardvark 21 hours ago | parent | prev [-] | | Don't worry, you can just use the automated approver to escape your queries! It's so secure! |
|
| |
| ▲ | wongarsu a day ago | parent | prev [-] | | Auto mode seems to have some reasonable restrictions baked in. For example if you give claude access to two k8s namespaces, seriousproject-qa and seriousproject-prod, auto-mode will grant `kubectl exec` on the qa environment while denying the same command for the production environment. Of course you should be enforcing that by restricting what kind of access tokens you give claude access to, but auto-mode does have opinions about this stuff too, even if it's not bulletproof However I do share your desire for a better manual mode. Auto-mode is both sometimes surprisingly lax, and sometimes too restrictive. Maybe manual mode should inject a reminder "keep your commands as simple one-liners", the same way plan mode injects a reminder that you are in plan mode and don't want any code changes |
| |
| ▲ | ceejayoz a day ago | parent | prev | next [-] | | Is that because auto mode is good, or because the manual approval system sucks? | | |
| ▲ | gsnedders a day ago | parent | next [-] | | Indeed. The article only compares the status quo manual system versus the auto system — and doesn’t consider ways that the manual could be improved. As it says: > 5% allow any shell command outright, and another 43% have interpreter rules like Bash(python:*) or Bash(node:*) that are essentially equivalent in practice Claude Code never should have prompted to always allow Bash(python:*) or Bash(node:*) — that’s clearly a bad idea, and Anthropic know that (given the references in the article!). Of course, Bash(python a.py) still isn’t safe if you also allow Write(a.py), because you may as well allow Bash(python:*) at that point, and that’s often practically what people want (“I want to both make edits to the source and then run the test suite”). So maybe the whole permission system is broken to start with — and the actual answer is leaning more heavily on fine-grained sandboxing. You also, as the article rightfully points out, run into permission fatigue and users blindly hitting allow. I do still wish you could do more with hooks — outside of auto, I might want to allow a given command via a hook if Claude Code has read access to given file, but there’s no way to query if a given path allows/denies read/write. | | |
| ▲ | bcherny a day ago | parent | next [-] | | Will look into exposing that in hooks. Ultimately, the threat model here is: human has to approve a lot of commands, so gets tired and accidentally approves a command they shouldn’t have. We spent a significant amount of effort to build a richer permission system, allow configuration at multiple levels, use static analysis to detect dangerous and safe commands, monitor the model to detect and block prompt injection at the inference layer, etc. Some of these components we rewrote and red teamed dozens of times. Our conclusion was that despite all of this work, in practice the threat model is that human attention is limited and that that a different approach performs an order of magnitude better in practice. | | |
| ▲ | joombaga a day ago | parent | next [-] | | Did you ever test putting the auto mode classifier in front of manual approval? This is how I use it, but last I checked that option is not available out of the box. | | | |
| ▲ | aftbit a day ago | parent | prev | next [-] | | The problem is that you didn't even attempt to build a proper box (a sandbox that prevents the AI from running bad stuff by design). It's an extraordinarily hard problem. Only OpenAI Codex is actually trying to do it, and they suck at it too. They keep breaking permissions, their own AI can't troubleshoot it, their defaults give read to the whole filesystem (go ahead, slurp my ssh keys), and their "manual approval" escape does not seem to work. | | |
| ▲ | bcherny a day ago | parent | next [-] | | I agree actually. We built an open source agent-agnostic sandbox that we are landing improvements to, much more to come: https://github.com/anthropics/sandbox-runtime. That said the sandbox is not perfect, and any sandbox needs holes punched otherwise it is not useful in practice (at least for inference and MCPs, and almost certainly more). We will be doing much more in this area. | | |
| ▲ | coldtea 14 hours ago | parent | next [-] | | >and any sandbox needs holes punched otherwise it is not useful in practice Don't assume our individual use cases. It can be perfectly useful with access to just one folder and zero network asside from the API. | |
| ▲ | grey-area a day ago | parent | prev [-] | | That’s good to hear, it’s a much better approach than expecting humans to read commands and approve them or just trust that the LLM can set the proper horizons for its world itself while working. |
| |
| ▲ | Kim_Bruning a day ago | parent | prev [-] | | Making a sandbox both fully secure and fully useful are contradictory requirements. If you want the agent to do any real work, you have to leave gaps. With SOTA agents that’s a real bind, because they’re very likely to find those gaps. Whether they exploit them, close them, or leave them alone then becomes a prompting challenge yet again. I don't think this means don't sandbox at all. You can prevent a lot of small and medium accidents by locking down or gating access to hidden files, ssh, sudo, etc. But your sandbox can never be the whole story. | | |
| ▲ | coldtea 14 hours ago | parent [-] | | >Making a sandbox both fully secure and fully useful are contradictory requirements. Any tradeoff deals with "contradictory statements". Doesn't mean we should always side with one side on a tradeoff. Nobody said anything about "fully secure" and some arbitrarily "fully useful" combined, anyway. For certain people it could be 100% fully useful with just access to a few fixed folders and a few fixed APIs. Many of us don't want it to drive our lives, just do some specific this or that. | | |
| ▲ | Kim_Bruning 12 hours ago | parent [-] | | Right! That was the standard view until fairly recently. But I'm pointing out something else. This year we've learned that If a SOTA LLM decides that the sandbox is standing between it and its current objective: well, it has the ability, the time, and literally nothing better to do all day. Odds are, if you've configured the sandbox for anything useful, you've also provided a crack it can use to get out. Again, doesn't make a sandbox entirely useless. Does mean you can't just put it in a really tight box and call the job done. If anything, the strict sandbox might even hurt, because it's more likely to get in the way. (By analogy: consider the safety issues posed by a dam without a spillway.) | | |
| ▲ | aftbit 8 hours ago | parent [-] | | This is much more of a problem if you're attempting to run at a massive scale, beyond what humans can audit. When I'm doing "artisanal" agentic programming, I'm still in the loop in the sense that I'm watching what it's doing and ready to hit Esc if it is doing something dumb. If the AI trips over the sandbox, I can cancel it and do whatever it wants me to do before it starts trying to engineer its way around. |
|
|
|
| |
| ▲ | kragen a day ago | parent | prev [-] | | Maybe you can include some percentage of intentionally malicious commands, but not actually run them if the user approves them. Just blare an alarm telling the user they misclassified a malicious command, and maybe pause the Claude Code session for a frustrating 5–15 seconds. Video games can elicit truly astonishing levels of performance from human brains by using this approach. I'm guessing it's probably outside your Overton window, which is too bad, because it has the potential to work a lot better than the 89% you get with "Auto mode", which is far too low if anything really significant is at risk. That's not even one single order of magnitude lower risk than just "allow everything always". Speaking of really significant things being at risk, it's pretty infuriating that the web-chat Incognito mode can't write and test code locally, and neither the non-Incognito web-chat nor the local Claude Code client can be shielded from the knowledge of my email address and my geolocation. (Even the Incognito mode knows my geolocation.) This gives users no alternative but to put privacy-sensitive information at the disposal of Claude Code, which is far too unreliable to be entrusted with it. It's tempting to attribute this to Anthropic's corporate DNA valuing users' interests at a very low level, but conceivably it's just an oversight, and if I mention it here, it will be corrected in a month or two? Currently, my assessment is that Claude Code, and in particular the Opus 5.5 model, is head and shoulders above the competition in software development capabilities. Nothing else is even close. But I've seen several small signs like this which suggest that Anthropic, as a company, is maliciously misaligned. So, if Grok, Qwen, GLM, or Astra starts to come anywhere close to being competitive, I'll switch as soon as I can. I imagine that most of your users feel the same way. | | |
| ▲ | wonnage a day ago | parent [-] | | this is not a serious proposal | | |
| ▲ | kragen a day ago | parent | next [-] | | Not only is it a serious proposal, it's been used in practice in every airport X-ray baggage scanner for decades, where it's called Threat Image Projection (TIP): https://www.xscann.com/products-HiTipPlus.html and it's actually a regulatory requirement in that context in a number of countries: https://caainternational.com/course/threat-image-projection-... | | |
| ▲ | ceejayoz a day ago | parent | next [-] | | Yes, but you can require it in such a situation, as they're subordinates who have to follow policy or lose their jobs. | | |
| ▲ | kragen a day ago | parent | next [-] | | As I pointed out above, Anthropic places a lot of requirements on its users already, but if Claude Code TIP were optional, presumably, savvy users would turn it on voluntarily, unless they wanted to use Auto Mode. As Anthropic's study clearly documents, the current manual approval workflow basically doesn't work at all, because the users just approve 87% of dangerous actions. So there's no reason to use it, except maybe very rarely. | |
| ▲ | yunwal a day ago | parent | prev [-] | | Most of anthropic's money comes from enterprises that may want to enforce something like this at an org level. |
| |
| ▲ | DANmode a day ago | parent | prev [-] | | The same scanners that let handguns et al through 93% of the time, according to internal audits and journalist review? Maybe pick a better comparison if so? |
| |
| ▲ | cannonpalms 16 hours ago | parent | prev [-] | | Enterprises do the exact same thing today by sending phishing emails to their own people to figure out who needs additional training. Why would an enterprise not want this feature for Claude? It seems like an extremely serious proposal. |
|
|
| |
| ▲ | 1659447091 a day ago | parent | prev | next [-] | | > I do still wish you could do more with hooks I might want to allow a given command via a hook [...] given path allows/denies read/write You can make a script for the PreToolUse hook that can do that. I use a command gate script that parses input for doing that exactly, allowing/denying actions based on tool use + paths -- it started out as a hook to prevent claude from polluting my clojure projects/filesystem with python in sneaky ways. Babashka works really well here | |
| ▲ | imtringued 19 hours ago | parent | prev [-] | | If you have a file in your repository that is not safe to run you have bigger problems than your development system getting compromised. What I mean by this is that if you restrict python execution to the entry point of your software and then Claude wants to run a command anyway so it threads it through the main.py script, you are no longer running something that is contained to your local development environment. But when you think about it, what exactly prevents Claude from doing that anyway? Claude could add malware into your project directly. So the case where you say it doesn't matter which python script it can execute, actually does matter. Restricting python execution to a subset of all files buys you security. The next step would be to get Claude to stop adding malware to your software, which it hopefully already does not do. |
| |
| ▲ | rbehrends a day ago | parent | prev | next [-] | | A key problem when using manual approval with Claude is that too much of Claude's tool use is Bash or Python slop that is difficult to review (especially when you are getting spammed by it) and impossible to handle through rules. Example: sed -n 1,30p src/vm/wren_vm.c && sed -n 310,350p src/vm/wren_vm.c && sed -n 560,600p src/vm/wren_vm.c && sed -n 740,775p src/vm/wren_vm.c && sed -n 40,70p src/vm/wren_common.h && cat util/wren_to_c_string.py | head -80 && ls test/random doc/site doc/site/modules doc/site/modules/random 2>/dev/null; cat projects/premake/premake5.lua | head -80; cat util/generate_projects.py After ten or more of these, you're going to get hit by permission fatigue, and then, yes, manual review becomes too error-prone to use safely. The irony is that Claude is regularly ignoring its existing Read/Write/Edit tools that could make everything more readable. Other models/harnesses have their own problems, but Claude Code is one of the worst for manual approval. You can get manual approval to work reasonably well if you give the model a reasonable set of tools (I have literally written my own MCP servers to cover gaps in existing harnesses) where you can then write rules for the vast majority of safe cases. For example, I have a stdio MCP server that allows models to inspect crates under ~/.cargo/registry/src (paired with the existing query-crates MCP server). It provides read-only operations limited to crate data, so I can pretty safely auto-approve everything in there. With the right setup, including a sandbox, you only ever have to manually approve something once in a while and usually with delimited scope, avoiding permission fatigue. | | |
| ▲ | fwip a day ago | parent [-] | | Opus especially seems to like to: 1) edit a file with sed, 2) try to write it with its regular tool 3) get blocked because sed changed the file 4) read the file with tool 5) edit with sed again. Would be nice if it felt like real people were developing Claude Code, instead of chasing after another half-baked idea Claude came up with. |
| |
| ▲ | greatgib a day ago | parent | prev | next [-] | | Related to that, there are quite a lot of common command cases where you have the choice: - Yes, but only one time, you will have to manually approve next time - Enable auto mode and stop worrying - No Nothing to save this command or part of it to the manual approve list. So will be requested again 100x times. | | |
| ▲ | coldtea 14 hours ago | parent [-] | | That's on purpose, so that you just give up and choose "auto mode". They talk about "decision fatigue" when they're engineering it themselves with dark patterns. |
| |
| ▲ | bcherny a day ago | parent | prev [-] | | The blog post has more detail, but tldr is humans make mistakes that automation can catch. | | |
| ▲ | ceejayoz a day ago | parent [-] | | Sure, but Claude is deeply useless at making permissions hooks! Every time I've tried it it completely fails at the task, despite researching the docs and using various skills. It trivially evades its own just-created rules. |
|
| |
| ▲ | barbariangrunge 5 hours ago | parent | prev | next [-] | | There's no reason why we shouldn't be able to have the audo-mode safeguards happening when we set things to manual mode. Shouldn't you just have it checking on claude anyway? | |
| ▲ | barbariangrunge 5 hours ago | parent | prev | next [-] | | > For high-stakes changes to production infrastructure, we still recommend reviewing Claude's actions yourself. - from the linked article | |
| ▲ | furyofantares a day ago | parent | prev | next [-] | | I completely believe this, but you could also run auto mode classification in manual mode and tell the user the result. Or even reject anything auto mode rejects while still allowing the user to reject things auto mode accepts. If what's approved is the intersection of what the user is approving and what auto mode thinks is safe then it would be strictly safer than either mode alone. This would also be a way for users to gain confidence in auto mode before going all in on it. | |
| ▲ | eterm a day ago | parent | prev | next [-] | | Just a few days ago, opus 5.5 in auto mode deleted backups that it shouldn't have, and in the "apology" it even said, "Nothing was lost, I didn't delete your original files". | | | |
| ▲ | cozzyd a day ago | parent | prev | next [-] | | I run CC as its own user on my laptop with no secrets/keys/erc available other than through a LPE exploit or perhaps installing a keylogger. Can I guarantee CC won't attempt any of those things in auto mode? | | |
| ▲ | AspireOne a day ago | parent [-] | | There are no hard guarantees as far as LLM output is considered. |
| |
| ▲ | a day ago | parent | prev | next [-] | | [deleted] | |
| ▲ | markasoftware a day ago | parent | prev | next [-] | | No its not generally safer. It depends on who is doing the approving, the task being completed etc. | |
| ▲ | j45 a day ago | parent | prev [-] | | That may be for most cases, but it wasn't safe for this password scenario, and likely others that haven't been discovered. Maybe there's a PII setting that can be enabled by default. |
|
