Show HN: Multitui – sandbox claude/codex/gemini on macOS without containers

Show HN: Multitui – sandbox claude/codex/gemini on macOS without containers(multitui.com)

1 points by davidcann 103 days ago | 3 comments

I made Multitui to control the sandbox of coding agents easily without changing my dev environment (no special container or VM). There's no configuration required in your local dev environment... just launch ClaudeCode.app instead of claude in your general terminal. Containers and VMs can be useful, but I always have a bunch of projects going and those solutions feel heavy.

Multitui creates single-purpose native macOS apps for any terminal app, with optional sandbox. It uses the built-in macOS sandbox-exec along with log monitoring to give you an easy UI to manage rules, see what's being blocked, and add rules as you observe files that need to be allowed.

https://multitui.com

Does this seem useful? Does it need network sandboxing too?

Also, it's on Product Hunt today, so an upvote would be appreciated!

https://www.producthunt.com/products/multitui

-David

longtermop 103 days ago |

Really nice approach using macOS native sandboxing! The deny-by-default with targeted allows for project folders is the right model.

To answer your question about network sandboxing: yes, it's arguably the more critical half. Filesystem damage is recoverable (backups, git), but credential exfiltration is not. The "lethal trifecta" for agent security is untrusted input + tool access + external connectivity. Your tool addresses #2 beautifully; network controls would complete the picture.

A few thoughts from building similar protections:

1. Network egress by hostname is more useful than blanket deny. Agents legitimately need to hit LLM APIs, but a compromised agent shouldn't be able to POST to arbitrary endpoints. Little Snitch integration could work here, or a simple proxy allowlist.

2. Credential injection timing matters. The Deno Sandbox approach (secrets as placeholders until request time, only injected for approved hosts) is clever for preventing exfiltration even if the agent is compromised.

3. The sandbox-exec deny log UI is gold. Making blocked actions visible is what lets users actually adopt restrictive policies instead of disabling them when something breaks.

One edge case to consider: agents spawning subprocesses (npm install, pip, brew) that need different rules than the parent. Per-command policy inheritance gets tricky.

Would love to see this pattern on Linux too - Landlock + seccomp could achieve similar results.

itay-maman 103 days ago |

I understand this macOS based. Do you think it can be ported to Linux (my intuition tells me this very macOS-specific, but maybe I am missing something)?

davidcann 103 days ago | |

The same concept is possible on Linux, but I don't think anyone has created a nice UI for it yet. There was a post yesterday about doing it on the command line in linux: https://news.ycombinator.com/item?id=46874139

One of the nice things in Multitui is that it monitors what is blocked and gives you a way to add a read/write rule from the UI.