Multitui is a macOS app factory that generates individual terminal apps for TUI programs, with optional sandbox. Create dedicated native apps for claude code, codex, gemini, lazygit, harlequin, or any TUI.
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 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.
The apps you create are highly customizable and provide many native macOS integrations (document-based app model, Finder integration, global shortcut, etc). It's built with Swift, so it's fast and lightweight.
I also like the idea of TUIs being first-class apps, like what Omarchy did on linux. It helps me context-switch better than cycling through ten similar-looking tabs in Ghostty.
It's free in beta and free for personal use forever!
Report
Congrats on the launch — love the idea of giving coding agents a controlled execution environment. One question from a standards/consistency perspective: how granular can the sandbox rules be? Do you allow defining reusable rule sets or patterns for file access, so the agent behaves consistently across different projects?
@dris_keddy The rules are pretty granular and are per-app that you create, like the Claude Code app template has rules for paths that Claude Code needs (~/.claude/*, etc), then when you open a project folder, claude has write access to your project folder. This makes the Claude Code app reusable for multiple projects.
However, if you have a more complicated project with several folders, you can create an app (like ComplicatedProject.app) dedicated to just that project and very specific rules (including regex!) for that app... you would set the default working directory to `~/complicatedproject` and the command field to `claude`.
Report
The sandbox-exec approach feels like the right level of isolation for coding agents without the overhead of containers. I especially like the log monitoring UI for observing blocked actions in real time. Does the log view support filtering or searching through past blocked events? When debugging why an agent failed mid-task, being able to quickly trace which specific file or syscall was denied would be really useful.
@yamamoto7 The log is sorted by time and I haven't seen the list get long enough where it's difficult to find important things that were blocked, so it doesn't currently have a filter. It does open into a full window, though, so perhaps some options could be added there, like filtering and exporting the log.
Report
Thanks for the explanation! The full window mode sounds like a good place for future features. Exporting would be great for post-mortem analysis when debugging why a long-running agent session failed.
Report
This is exactly what vibe coding needs - the sandbox approach is smart. Been seeing too many people run coding agents with full system access, not realizing what can be exfiltrated. The network sandboxing idea for preventing secrets theft would be huge. Most security issues I've seen in AI-generated code aren't runtime vulns - they're leaky APIs, hardcoded creds, or packages that phone home.
Report
This solves a real problem. I've been running Claude Code for months and the "just trust it" approach to file system access is... uncomfortable. Especially when you're working across multiple projects and one agent could theoretically touch files from another.
The sandbox-exec approach is smart - native macOS sandboxing without the Docker/VM overhead. How does it handle when Claude Code needs to install npm packages or run build scripts? That's usually where sandbox friction kills the workflow.
Report
Congrats on the launch — love the sandboxed TUI app factory approach on macOS.
@zeiki_yu Thanks! I'm thinking about adding network sandboxing to prevent code and secrets stealing, like Little Snitch, but more fine-grained.
Report
"sandboxing" is the killer feature here giving claude code full terminal access feels like playing russian roulette with my file system. does the sandbox also allow us to restrict network access, or is it just file permissions?
Multitui
Congrats on the launch — love the idea of giving coding agents a controlled execution environment. One question from a standards/consistency perspective: how granular can the sandbox rules be? Do you allow defining reusable rule sets or patterns for file access, so the agent behaves consistently across different projects?
Multitui
@dris_keddy The rules are pretty granular and are per-app that you create, like the Claude Code app template has rules for paths that Claude Code needs (~/.claude/*, etc), then when you open a project folder, claude has write access to your project folder. This makes the Claude Code app reusable for multiple projects.
However, if you have a more complicated project with several folders, you can create an app (like ComplicatedProject.app) dedicated to just that project and very specific rules (including regex!) for that app... you would set the default working directory to `~/complicatedproject` and the command field to `claude`.
The sandbox-exec approach feels like the right level of isolation for coding agents without the overhead of containers. I especially like the log monitoring UI for observing blocked actions in real time. Does the log view support filtering or searching through past blocked events? When debugging why an agent failed mid-task, being able to quickly trace which specific file or syscall was denied would be really useful.
Multitui
@yamamoto7 The log is sorted by time and I haven't seen the list get long enough where it's difficult to find important things that were blocked, so it doesn't currently have a filter. It does open into a full window, though, so perhaps some options could be added there, like filtering and exporting the log.
Thanks for the explanation! The full window mode sounds like a good place for future features. Exporting would be great for post-mortem analysis when debugging why a long-running agent session failed.
This is exactly what vibe coding needs - the sandbox approach is smart. Been seeing too many people run coding agents with full system access, not realizing what can be exfiltrated. The network sandboxing idea for preventing secrets theft would be huge. Most security issues I've seen in AI-generated code aren't runtime vulns - they're leaky APIs, hardcoded creds, or packages that phone home.
This solves a real problem. I've been running Claude Code for months and the "just trust it" approach to file system access is... uncomfortable. Especially when you're working across multiple projects and one agent could theoretically touch files from another.
The sandbox-exec approach is smart - native macOS sandboxing without the Docker/VM overhead. How does it handle when Claude Code needs to install npm packages or run build scripts? That's usually where sandbox friction kills the workflow.
Congrats on the launch — love the sandboxed TUI app factory approach on macOS.
Multitui
@zeiki_yu Thanks! I'm thinking about adding network sandboxing to prevent code and secrets stealing, like Little Snitch, but more fine-grained.
"sandboxing" is the killer feature here giving claude code full terminal access feels like playing russian roulette with my file system. does the sandbox also allow us to restrict network access, or is it just file permissions?