No way to submit bug reports other than email - I'll forward this.
How about at least a GitHub stub repo for Issue reports?
Lot's of permissions (but missing "Full Disk Access" in the UI setup flow)
I didn't know it also needed FDA until I did "ash status".
Why is there a Login?
GitHub login broken - 404.
No Source - This is a security tool that can't be audited.
You had your 5 minutes on HN, but you'll need the community for Linux and Windows.
Yeah, overloaded name - how about AgSh.app / agsh?
It's not too late to fix it.
Your feedback about permissions is something I'm working on fixing now. Apple requires multiple permissions for Endpoint Security and Network Extension APIs and the current setup process doesn't walk users through that process as elegantly as I would like it to.
this is great. The environment variable control is particularly interesting to me. I've been working on a related problem but different approach: encrypting/decrypting secrets using the Mac's secure enclave (https://github.com/keypo-us/keypo-wallet/tree/main/keypo-sig...). The two approaches seem complementary: Ash controls the perimeter, encrypted vaults protect the values themselves.
Great tool! I've witnessed numerous cases where novice users lost critical data assets by recklessly granting proxies/AI agents excessive permissions without understanding the security implications.
the network restriction question is the interesting one for agent sandboxing — the real risk isn't the agent reading files it shouldn't, it's exfiltrating data through api calls to attacker-controlled endpoints. for agent-to-agent payment protocols like x402 the question gets weird: the agent needs outbound to pay for data, but you want to allowlist which endpoints it can call. per-process network policy + endpoint allowlisting seems like the right primitive here
One thing that comes to mind is whether the sandbox can restrict outbound network access per process or per command. That could be useful for preventing agents from silently exfiltrating data while still allowing limited API calls.
love the tool but the name is used by a lot of folks. I'll try it regardless though. was just talking to someone about this very thing today during a meeting
Yeah, the underlying sandbox technology between Ash and CC is fundamentally different.
Ash is built on the Endpoint Security and Network Extension APIs. Together, they cover the full gamut of potential sandbox escapes, and it's a simple process to update sandbox rules while the sandboxed process is running.
Claude Code sandbox is built mainly on sandbox-exec, an older macOS sandbox technology. It works for filesystem and IO device control, but it can only filter network requests by IP address. CC uses an application-level network proxy as a workaround, but not every network client respects the HTTP_PROXY env variable it requires. There are other workarounds in CC sandbox for complex use cases (e.g. dangerouslyDisableSandbox) that Ash does not need.
I'd be interested in seeing a breakdown in which ones use:
- VMs
- Containers
- sandbox-exec (macOS builtin tool)
- Endpoint Security + Network Extension (AFAIK this is just Ash but it would be good to see company here)
No way to submit bug reports other than email - I'll forward this. How about at least a GitHub stub repo for Issue reports? Lot's of permissions (but missing "Full Disk Access" in the UI setup flow) I didn't know it also needed FDA until I did "ash status". Why is there a Login? GitHub login broken - 404.
No Source - This is a security tool that can't be audited. You had your 5 minutes on HN, but you'll need the community for Linux and Windows.
Yeah, overloaded name - how about AgSh.app / agsh? It's not too late to fix it.
Good idea about the GitHub stub repo, I've added it here: https://github.com/Ash-Sandbox/bugs.
Your feedback about permissions is something I'm working on fixing now. Apple requires multiple permissions for Endpoint Security and Network Extension APIs and the current setup process doesn't walk users through that process as elegantly as I would like it to.
this is great. The environment variable control is particularly interesting to me. I've been working on a related problem but different approach: encrypting/decrypting secrets using the Mac's secure enclave (https://github.com/keypo-us/keypo-wallet/tree/main/keypo-sig...). The two approaches seem complementary: Ash controls the perimeter, encrypted vaults protect the values themselves.
I believe you’re late to the “ash shell” name by about 36 years
https://en.wikipedia.org/wiki/Almquist_shell
Great tool! I've witnessed numerous cases where novice users lost critical data assets by recklessly granting proxies/AI agents excessive permissions without understanding the security implications.
the network restriction question is the interesting one for agent sandboxing — the real risk isn't the agent reading files it shouldn't, it's exfiltrating data through api calls to attacker-controlled endpoints. for agent-to-agent payment protocols like x402 the question gets weird: the agent needs outbound to pay for data, but you want to allowlist which endpoints it can call. per-process network policy + endpoint allowlisting seems like the right primitive here
Yeah I think that's a good point. I've added process-specific network access to the roadmap: https://github.com/Ash-Sandbox/bugs/issues/1
One thing that comes to mind is whether the sandbox can restrict outbound network access per process or per command. That could be useful for preventing agents from silently exfiltrating data while still allowing limited API calls.
Yeah I like the idea of allowing the sandbox to restrict network connections to specific processes. I'll put it on the roadmap: https://github.com/Ash-Sandbox/bugs/issues/1
love the tool but the name is used by a lot of folks. I'll try it regardless though. was just talking to someone about this very thing today during a meeting
Looks cool, I'll give it a shot. Is this any different from /sandbox command?
Yeah, the underlying sandbox technology between Ash and CC is fundamentally different.
Ash is built on the Endpoint Security and Network Extension APIs. Together, they cover the full gamut of potential sandbox escapes, and it's a simple process to update sandbox rules while the sandboxed process is running.
Claude Code sandbox is built mainly on sandbox-exec, an older macOS sandbox technology. It works for filesystem and IO device control, but it can only filter network requests by IP address. CC uses an application-level network proxy as a workaround, but not every network client respects the HTTP_PROXY env variable it requires. There are other workarounds in CC sandbox for complex use cases (e.g. dangerouslyDisableSandbox) that Ash does not need.
There's a shell with the exact same name for Unix
And there’s also the Ash framework for Elixir.
This looks cool
See also various sandbox tools I and others (e.g. jpeeler) have collected: https://news.ycombinator.com/item?id=47102258
I'd be interested in seeing a breakdown in which ones use:
- VMs - Containers - sandbox-exec (macOS builtin tool) - Endpoint Security + Network Extension (AFAIK this is just Ash but it would be good to see company here)