Retired Kivy.org core dev
Modular music enthousiast
23 years in, still debugging
Experimented with a FUSE filesystem sandbox for greywall. Gave up on Landlock, wanted dynamic rules and actual observability instead of a black box.
Rules are simple: "only git can touch .git/**". First match wins. Runs rootless, no sudo. Every file operation streams as JSONL.
No, Claude can't read your .env. But if it needs git? Fine, that's allowed. Per-caller semantics feel like the right direction for agent sandboxing.
Experimenting with the idea of a "living sonic ecosystem" driven by computer activity. I'm looking at proxy traffic, CPU, and agent actions that can act as perturbations in a self-regulating audio world. My own audio landscape.
We just launched on Product Hunt and would love your feedback: https://producthunt.com/products/greywall?launch=greywall
If you use Claude Code, Cursor, Codex, or any AI agent daily: have you ever actually looked at what your agent connects to? Curious what others are finding.

AI agents run on your machine, with your credentials, making network requests you never see. Greywall puts a deny-by-default layer in front of any CLI agent. Run greywall -- claude and it restricts file access, blocks outbound connections, and shows you a live dashboard of what the agent is trying to reach. You decide what to allow. Nothing is containerized. Your workflow stays the same but safer. It runs on Linux and macOS and costs nothing.
Linux + greywall: read .env, substitute placeholders live, write temp file, bind-mount into sandbox. Agent sees zero friction.
macOS? No bind mount. sandbox-exec doesn't support it. Looking at FUSE.
Just implemented credential protection in greyproxy. Instead of seeing real API keys values, the agent gets opaque `greyproxy:credential:v1:xxx` placeholders.
The proxy swaps them back before forwarding upstream. Agent never touches the actual key. #greywall #greyproxy