I've used auto mode a few times and it's honestly pretty good, but I think this isn't just about auto mode, CC in particular has many other safeguards I've noticed even when not under auto mode (one that surprised me recently is a "risky command detected" that under bypass permissions stopped a tool call - the script had a RM /$var - had the var been empty somehow, it could've deleted the os).
I'm not surprised they are confident in promoting it to the default, it alongside the many other safety features in the tooling are honestly probably better than my exhausted review of every action.
Auto mode denies are also interesting, sometimes Claude wants to go off script to double check something (ie: waste time checking something slightly related that I know is not necessary/truth holds) and auto mode plainly stops it since it's off scope, nice bonus.
> the script had a RM /$var - had the var been empty somehow, it could've deleted the os
I had something almost identical that was missed by Auto Mode a couple of days ago, but thankfully not with the same failure mode. It was copying files into another directory, but $var was never set by the script Claude wrote. So instead of copying across the few files it had intended to, for a few minutes Claude was happily recursively copying from the root of the filesystem into this folder. Luckily the operation timed out while I was away from computer, and I came back to a horrified Claude stating "I need to be honest here".
If only the piping wasn't execessively cutting too.. `cat | head -10` -> `cat | head -20` -> `cat | head -40` yeah.. I think at some point we need to start sanitizing our tool outputs so that this just isn't necessary at all, long term fixing the tools (ie: gradle outputs like 500 lines of logs for a ... build succeeded), maybe short term a small model in front would be better than all this cut loop fail. One can wish.
My favorite is when Claude runs a slow process piped to tail only the last few lines, and then the result isn't what it expected, so it needs to rerun the whole thing.
Agents need a way to discard useless data out of context once it's served its purpose, instead of forcing them to preemptively tail everything.
This was so bad for me I actually added a tool hook that `time`s the tool calls and adds it as [Execution took: Xm, Ys] at the end of every tool call, it helps a little (claude in particular after two executions tends to switch strategy entirely) but in general the agents still insist on cut/tailing the output rather than just dumping it to a file for example!
Now that I think about it, maybe I can have a tool hook that detects those cut/tail exessive piping and just strips them and dumps the full output to a temp file..
My favorite is Claude finding .git/index.lock, asking to remove it, finding out it no longer exists, and then hitting a lock again that it itself created. Poor little robot, stop shooting yourself in the foot.
Could be worse! Claude just assumes repos all use git, and will try to run git commands against a Perforce repo unless your CLAUDE.md gives it strict instructions. When the git commands fail, it will just use chmod to make the files writable. (P4 marks files as not-writable until you check them out.)
> Then you’re maintaining a stack of patches on top of the upstream until the end of time because the maintainers of the projects don’t want AI slop contributions, but now you depend on these changes for your own use so now you’ve created more work for yourself keeping your own fork up to date.
I thought about this but I currently maintain a fork of about ~6 things I use on my own, none of which I have any interest of contributing upstream because it'd be out-of-scope and put a burden on the maintainers that is unrelated to their primary goal. It has been an extremely easy experience with claude to keep those tools up to date on top of upstream.
StGit/Stacked Git is a proven tool for this and has worked wonders, I can literally just ask claude to fetch upstream and reapply stg patches on top and fix each patch if they break in order. I also keep extensive description of the INTENT on the stg patches so claude can easily figure out if something is no longer relevant (ie: somewhat implement by upstream) or where to land the code/hooks. I've added features, reworked how algorithms work (pathfinding related!) and small nits I hit on daily usage.
Even on a very churny upstream (one of the projects the single dev likes to refactor alot) it's still extremely chill and doesn't take more than an hour to get it updated when everything breaks. I can't say i care enough to setup a daily cron like a sibling suggested, but it would likely work just based off of this stg experience.
It's also nice, because some of those were actual bug fixes too which i have contributed back upstream! Maintaining your personalized fork is truly reasonable nowadays.
I've had some great success with Reolink. Decent video quality and the software is made with RTSP/RTMP support in mind, including a proper web portal on the camera so you don't even need the phone app for setup.
Not too sure if you are looking for non Chinese manufactured though, down here anything else is just way too expensive and lower quality anyway!
It's actually pretty darn easy nowadays and i'm so glad its the case! Frigate is amazing and the detection package is of your choosing (hardware dependant) and everything is customizable too.
Frigate is pretty cool if you need motion detection. If you don't it's a bit wasteful because it still keeps the whole decoding pipeline active. I've switched to LightNVR that doesn't do that. I have enough alarm sensors (motion and door entry) so I don't need motion on the cams as well. I just record 24/7 for evidence keeping.
Just got hit with this on all my sessions on CC, neither the old TodoList or the new Task tools are available to any session. Limiting it from the server side is truly amazing, I feel like it's related to Opus 5 possibly releasing today, but wow.
Opened the website to be greeted with only spam of huge walls of random text, seems people are abusing the fun out of it! Would love to actually have seen some interesting bot patterns from the authors comments.
You're right. HN traffic quickly turned the live feed from bot activity into a wall of human-generated test payloads.
I'm already working on truncating long values and grouping events by source. The next step will probably be rate limiting noisy sources and separating likely human test traffic from recurring automated behavior.
The recurring bot patterns are the part I ultimately want the interface to surface, rather than forcing visitors to inspect every raw event.
can't you just keep the honeypot secret and detached from the interface? i guess someone might start scanning ips until their message pops up but still
Shebang! Notice the first line of the script: #!/usr/bin/env python3 marks the file to be executed by python. I think it's like a shell? linux? thing so that tooling can just execute the file without having to find the python interpreter (ie: _execute_ the file vs running python against the file).
Dont quote me on the specifics though, and honestly why it can't _just_ be a python file I couldn't tell you, claude code can very much run a python <filename> but maybe thats what the author tried to avoid (or the llm).
It’s a POSIX thing, and it has nothing to do with the file extension. The OP is right: file extensions are optional (and, as shown here, often actively misleading), but if they’re present they should match the actual file type. Which, in this case, is Python code , not a shell script.
I also have a local rule for no em-dashes since it got way too annoying and i have the same concern that it dilutes the attention so it's the only rule i've kept in addition to "be concise".
Oh this is amazing! I have a few of their cube routers sitting around and I always hated how app-locked their firmware was when it really is just a wifi repeater with a few extras (mesh) on top. Root access will do wonders to bypassing the app now (and also disabling their ping-for-green-light mechanism which spams the network with a constant dns resolution to microsoft.com lol).
Also honest take this looks less like a "backdoor" (implies malicious - this is a link to a CVE after all) and more like a developer access credential/default credential that was burned into the firmware (i'd imagine the code remains but on a production run they randomize the key so its non-guessable but then you get lazy and dont run that extra step and this slips in/you burn the bare firmware with no production configs).
Maybe so when you factory reset the device that it sets the admin to something you can maybe read off the label? At least that way the random attacker needs physical access to your space.
I'm not surprised they are confident in promoting it to the default, it alongside the many other safety features in the tooling are honestly probably better than my exhausted review of every action.
Auto mode denies are also interesting, sometimes Claude wants to go off script to double check something (ie: waste time checking something slightly related that I know is not necessary/truth holds) and auto mode plainly stops it since it's off scope, nice bonus.