Claude's willingness to poke outside of its present directory can definitely be a little worrying. Just the other day, it started trying to access my jails after I specifically told it not to.
On a Mac, I use built-in sandboxing to jail Claude (and every other agent) to $CWD so it doesn’t read/write anything it shouldn’t, doesn’t leak env, etc. This is done by dynamically generating access policies and I open sourced this at https://agent-safehouse.dev
By any chance, do you know what Claude Code's sandbox feature uses under the hood and how that relates to your solution ? From what I remember it also uses the native MacOS sandbox framework, but I haven't looked too deep into it and don't trust it fully
Claude Code sandboxing uses the same basic OS primitive but grants read access to the entire filesystem and includes escape hatches (some commands bypass sandboxing). Also, I wanted something solid I can use to limit every agent (OpenCode, Pi, Auggie, etc).
I haven’t found an easy way, but I have a working theory -
sandbox-exec cannot filter based on domain names, but it can restrict outbound network connections to a specific IP/port (and drop the rest). If I can run a proxy on localhost:19999, I can allow agents to connect through it and filter connections by hostname. From my research, most agents support $HTTP_PROXY, so I'll try redirecting their HTTP requests through my security proxy. IIRC, if I do this at the CONNECT level, I don't need to MITM their traffic nor require a trusted root cert.
Recently, Codex CLI implemented something like DNS filtering for their sandbox, so I'd investigate their repo.
Some commercial firewalls will snoop on the SNI header in TLS requests and send a RST towards the client if the hostname isn’t on a whitelist. Reasonably effective. If there’s a way with the macos sandboxing to intercept socket connections you might find some proxy software that already supports this.
The raft of outages lately (my company was disrupted by I think four last week?) have certainly (and deservedly) created some pent-up frustration. I'm personally frustrated with its poor performance on Safari.
Overall, though, it's ... fine. That's all. A little worse than it used to be, which is frustrating, but certainly nowhere near unusable. I stood up my own forge and mirror some repos to it. The performance is almost comically better. I know it's not a fair comparison: I have only one user. On the other hand, I'm on a 9-year-old Xeon located geographically farther from me than GitHub's servers.
fish is a bit insonsistent on it. For instance, `git add <tab>` will only autocomplete for modified files. It will also fill in wildcards, e.g. `cat *.txt <tab>` will expand to show all .txt files. On the failure side, `rm foo <tab>` will still show `foo` as an option.
IME, zsh has better autocompletion (which, at the time at least, was a separate install).
- completions being aware of previous options, flags, and values
A lot of completions have the first. Some have the second. The last is rare. The completer needs knowledge of when flags, options, and value can be repeated and change which future options and values are suggested.
ZFS will happilly (and intentionally) gobble up available RAM for ARC. On my 64GB system, ARC is using 42.4GB, but this memory is quickly reclaimable if it's needed. That said, I had very bad experiences trying to run ZFS on an underprovisioned system.
> The vast majority of humans are not benefiting from it and are therefore motivated against it.
The vast majority of humans do not benefit from you, personally, owning a car, but that doesn't mean we're all motivated to call a towing company to your house.
> Rust has a standard library that looks an awful lot like Python or Ruby, with similarly named methods.
Can you elaborate? While they obviously have overlap, Rust's stdlib is deliberately minimal (you don't even get RNG without hitting crates.io), whereas Python's is gigantic. And in actual use, they tend to feel extremely different.
It really isn’t, and especially not when one of the browser’s unique selling points is its multi-browser extension compatibility that no other browser offers.
Also some of us simply don’t want to learn new UIs and/or risk dealing with an “AI” infused alternative if we have a tool that already Just Works. Switching away from Just Works sucks.
The worst part about opera dying was the email client imnho - and it wasn't trivial to find a replacement.
I'm not sure what I'd seek in a browser I'd pay for - but it would be features not present or great in foss browsers.
Maybe email, podcast, rss client, a modal vi like browsing (like vimperator, but first class), a good reader mode/style override, proper editor for text input (like "it's all text"), automatic force support for select text, save as... for images)...
But whatever would be useful enough to pay for, would likely be a pain to lose.
Granted it's not a giant list, but each release does have little refinements here and there, and Claude may have missed some (it didn't mention container CLI, for instance; that was from my memory). I also omitted some features I don't care about (like Safari profiles and some other window management stuff).
What features are you hoping for? Aside from a tiling WM, which won't happen, I'd be happy just with refinements and bug fixes.
I've used password-encrypted keys on a Mac plenty of times. It was easy to add them to the SSH agent to not require a password after initial authorization, if that's what I wanted. What is the issue I'm not seeing?
reply