What Is Sanductor? The Beginner's Guide to the Agentic IDE That Runs Coding Agents as a Sandboxed macOS User

CodexFuse Team · 2026-11-05T15:55:53.136Z · 27 min read min read

What Is Sanductor? The Beginner's Guide to the Agentic IDE That Runs Coding Agents as a Sandboxed macOS User

What Is Sanductor?

Sanductor is a free, native macOS app that runs OpenAI Codex and Claude Code as a sandboxed non-admin macOS user, so coding agents can work on your repositories without ever seeing your credentials, environment, or home directory. It is a Sanductor agentic IDE built by Mike McQuaid, the Homebrew project leader, and it organises parallel agent sessions into Git worktrees inside a three-pane window. Sanductor is open source under the AGPL-3.0 licence, and it has no account, no subscription, and no hosted relay.

So what is Sanductor, in one sentence? It is the Mac app McQuaid built for himself so he could let coding agents do real work on his projects without handing them the keys to his machine. The app was formerly called AgentIDE, and it was renamed to Sanductor in version 1.0.0.

It runs only on Apple silicon Macs with macOS 26 or later, and it is, in the author's own words, personal software without support or compatibility guarantees.

The trust model is easy to test in your head. An agent that cannot read your home directory cannot leak what it cannot see, in the same way a SHA-256 hash generator proves a file's contents without revealing anything else. Sanductor applies that idea to your whole Mac: the agent works in a shared workspace, and everything outside that workspace stays yours.

If you already run code on remote machines, VPS hosting is the usual way to keep that work separate from your laptop. Sanductor does the same job locally, on your Mac, with a second macOS user instead of a second machine.

This is a same-day explainer built only from primary sources. At the time of writing, no independent review, how-to, or hands-on article about Sanductor exists anywhere else. Everything below comes from McQuaid's own blog post of September 24, 2026, his product page, the GitHub repository, and the Homebrew listing, all fetched on November 5, 2026.

That matters because the numbers are small and young: the repository was created on August 1, 2026, which is 96 days before this article, and it had 65 stars, 11 forks, and 0 open issues when checked.

One clarification belongs up front, because the name invites confusion. Sanductor is the IDE. Sandvault is the sandbox layer it builds on, a separate tool that creates the non-admin user.

It is not Sandpack, the in-browser toolkit from CodeSandbox. It is not Sandfort, which builds disposable Linux virtual machines in UTM. It is not sanduk, a Python tool that runs agents inside disposable containers.

The shared idea is sandboxes. The products are not the same.

How Does the Sandboxed macOS User Model Work?

The Sanductor Sandvault pairing is the whole product: one app you see, and one sandbox layer you do not. The sandbox is the whole point of Sanductor, so it is worth understanding before anything else. Sanductor does not run your agents as you.

It runs them as a separate, non-admin macOS user created by Sandvault, the command line tool behind the sandbox, and that user can only touch a shared workspace. Your home directory, your environment, and your credentials stay on your side of the line.

The setup flow is short. You install Sandvault, run its build command, and authorise the setup. That creates the non-admin account and a shared workspace under /Users/Shared that both accounts can reach.

Repository paths must sit inside that workspace. Symlinks can point there, but they cannot grant access outside it. Agents cannot run brew install, so you install shared dependencies yourself from your own account first.

The credential boundary is the part McQuaid is most explicit about. Agents can read public repositories, but they have no GitHub credentials. The gh command line tool is only ever run as your own user, so agents never see it.

You run gh auth login as yourself, then start the agent from the sandbox account with its own agent login. Signing and pushing stay under your control too: the app never signs or pushes on its own.

That boundary is what makes the model different from simply running an agent in your terminal. A terminal agent runs as you, with your keys, your files, and your permissions. A Sanductor agent runs as a second user who can change the shared files and upload readable code, and whose work you review before trusting it.

The README says exactly that: agents can change shared files and upload readable code, so review their work before trusting it.

One honest caveat belongs here. A separate macOS user is not a strong security sandbox against determined malicious software. A community guide to the same technique warns that files in your main home directory that are world-readable can still be reached, and that the setup protects against accidental breakage rather than containing malware.

Sanductor's own framing is narrower and fairer: trust boundaries are enforced by user separation and sandboxing through Sandvault. It is a guard against agents doing the wrong thing, not a vault against an attacker.

Sandvault itself needs one careful note. There are two Sandvault repositories, and they are not the same thing. The upstream project is webcoyote/sandvault by Patrick Wyatt, under the Apache-2.0 licence, and the Homebrew sandvault formula points at it.

McQuaid's Sandvault repository is a fork of that upstream project. Which one Sanductor's setup actually uses, and how the fork differs from upstream, was not verified from any source fetched for this article. Treat the sandbox as Sandvault, and do not assume which fork is installed until you check.

The upstream Sandvault README also lists what the sandbox user can read: /usr, /bin, /etc, and /opt are readable, while other user directories are not accessible at all. That is the shape of the boundary. The agent gets a working system and a shared folder.

It does not get your life.

What Does the Three-Pane Layout Show You?

Sanductor's window has three panes, and each one has one job. The left sidebar lists your repositories and their worktrees, with branch and pull request status. The middle pane is where you talk to the sandboxed Codex or Claude Code agent.

The right pane is the multi-function side: review code and commits, look at pull requests and their blockers, edit code with syntax highlighting, open a shell, or read browser and application logs.

The typical session follows the same loop every time. You start from a prompt, an issue, a branch, an existing pull request, or an unpublished security advisory. The agent works in a worktree.

You review the code and the commits, iterate, and open a pull request. When CI fails or a reviewer leaves a comment, you feed that feedback back to the agent. Then you merge and delete the worktree.

McQuaid describes the happy path plainly: he sometimes does all of this without typing a single character, only clicking.

That loop is why worktrees matter. Each task gets its own worktree, so parallel agents never step on each other's changes. The sidebar shows which worktree belongs to which task, the middle pane shows the agent doing that task, and the right pane shows the result.

Nothing about the layout is exotic. The point is that the layout makes the sandbox visible: you can always see which agent is running, where it is running, and what it changed.

Review is built into the same window. You can review changes with a fresh agent session, with CodeRabbit, or with Copilot, including findings outside the diff. You can copy reviews and failed CI logs for pasting into agents.

An opt-in autofix feeds reviews, CI failures, and merge conflicts back to agents, resumes after relaunch, and still never signs or pushes. The app also tracks agents, pull requests, and blockers by repository or status, with bulk worktree actions and notifications.

How Do You Install Sanductor With Homebrew?

The Sanductor brew install path is a Homebrew cask, not a formula, and that distinction matters. A formula installs a command line tool. A cask installs a Mac app.

Sanductor is a Mac app, so the correct command is brew install --cask sanductor. The formula page for Sanductor returns a 404, and any article that calls it a formula is wrong. The author's blog and README also show the short form, brew install sanductor, which Homebrew resolves to the cask automatically.

Both forms install the same app, but only the cask form says what it is.

Five steps take you from nothing to your first sandboxed session.

1. Check the requirements: an Apple silicon Mac running macOS 26 or later, plus Homebrew, Git, and an account for Codex CLI or Claude Code.
2. Install the app with brew install --cask sanductor, which also pulls in its dependencies: herdr, ripgrep, gh, and sandvault.
3. Set up the sandbox with Sandvault: install sandvault, run sv build, and authorise the setup that creates the non-admin user and the shared workspace.
4. Sign in to GitHub as yourself with gh auth login, so the sandbox user never touches your credentials.
5. Open a repository inside the shared workspace, create a worktree and an agent session from a prompt or an issue, and review what the agent produces.

The requirements are strict about hardware. The Sanductor macOS requirements are Apple silicon and macOS 26 or later, with no exceptions in the sources fetched. Intel Macs are not supported, and older macOS versions are not supported.

Building from source needs Xcode 27.2 or later. The author's blog mentions that he required a macOS Golden Gate public beta, but the README and the cask page both state macOS 26 or later, so this article uses the documented requirement and does not equate the two names.

One small collision is worth knowing before you install. The sandvault formula conflicts with runit, because both install a command named sv. If you already use runit, you will need to resolve that conflict first.

The cask also ships two binaries, sanductor and agentide, the second being a leftover alias from the app's former name.

Which Coding Agents Can Sanductor Run?

Sanductor runs two agents: OpenAI Codex CLI and Claude Code. Those are the only two named in the README, the blog post, and the product page. Reviewers can also be fresh agent sessions, CodeRabbit, or Copilot, but the working agents are Codex and Claude Code.

If you want to learn how to use Claude Code on its own first, the guide on how to use Claude Code covers the setup and the daily workflow before any sandbox is involved.

The short version: Sanductor lets you run Claude Code sandboxed Mac-first, without a container or a virtual machine. The agent runs as the sandbox user, in a worktree, inside the shared workspace. You talk to it in the middle pane, and you review its work in the right pane.

Nothing about the agent itself changes. What changes is whose permissions it runs with.

Google Gemini is the one name to keep out of this section. Upstream Sandvault does support Gemini through its sv gemini command, but Sanductor's README does not list Gemini as a supported agent. Claiming Sanductor runs Gemini would be wrong.

The same care applies to prices: Codex CLI and Claude Code are separate paid products from OpenAI and Anthropic, and no pricing for them was fetched for this article, so none is stated here.

Parallel sessions are where the two-agent choice pays off. You can run a Codex session on one task and a Claude Code session on another, each in its own worktree, each as the same sandbox user, each visible in the sidebar. The app tracks them by repository or status, and it can schedule repository prompts daily, weekly, or monthly while it is open.

Shortcuts and Siri can start tasks and check blockers, and agent shortcut keys speed up the switching.

How Do Worktrees Keep Parallel Agents From Colliding?

A worktree is a separate working copy of a repository at a different branch, and it is the unit Sanductor organises around. Each task gets its own worktree, so two agents never edit the same files. One agent can refactor authentication while another fixes a failing test suite, and neither sees the other's half-finished work.

When the task is done, you merge and delete the worktree, and the sidebar goes back to one entry per live task.

Session multiplexing is what keeps those worktrees alive when the app is not. Sanductor builds on herdr, a small server called herdr-core that runs on the machine and holds the agent sessions, so they are not tied to the GUI window. Agents keep running after you quit or update the app.

Shell tabs close when you quit, but the agents survive. That is the difference between a window and a service: closing the window does not kill the work.

Herdr itself is a native app for running coding agents, open source under the Apache 2.0 licence and free. It supports spaces per repository, tabs per task, SSH machines in the same sidebar, and a status protocol that reports whether an agent is working, done, or blocked. Sanductor pulls in herdr version 0.9.5 as a cask dependency.

The phone side uses mosh for more responsive sessions over a connection that may drop.

Backups are part of the same design. Sanductor keeps agents running and reachable over SSH after quitting, with private backups and 30-day retention. Thirty days is the number the README states, so treat it as the retention window: a month of private backups, not forever.

Combined with the scheduled prompts and the bulk worktree actions, the picture is an app built for someone who runs many agents across many repositories and wants them all supervised from one place.

What Happens After an Agent Finishes Its Work?

Finishing is the start of the review loop, not the end of the job. The agent's changes sit in its worktree, and you review them in the right pane: code, commits, and the pull request with its blockers. You can ask a fresh agent session to review the work, or bring in CodeRabbit or Copilot, including findings outside the diff.

The point is that the code is checked by something other than the agent that wrote it.

Failures feed back into the same loop. When CI fails or a human reviewer leaves a comment, you copy that feedback into the agent and let it try again. The opt-in autofix does this automatically: it feeds reviews, CI failures, and merge conflicts back to agents, resumes after relaunch, and still never signs or pushes.

Signing and pushing stay under your control, along with rebasing, stacked pull requests, labels, merge queues, automerge, and cleanup.

The numbers behind the workflow are modest but they show a project moving fast. Fifteen releases in the 96 days from August 1 to November 5, 2026 is one release every 6.4 days. Seven hundred and forty-four commits across those 15 releases is 49.6 commits per release.

The 1.0.0 release notes list the AgentIDE to Sanductor rename, better session controls, CodeRabbit comments outside the diff, and a clarification of Sanductor safety and the maintainer workflow. Those are the notes of a tool being shaped by daily use, not a launch announcement.

McQuaid's own usage is the clearest statement of what the workflow replaced. The app replaced Superset entirely for him, and almost entirely replaced Fork and Zed, within about three weeks of building it. He built it over a weekend with Claude Max and Anthropic's Fable 5 model, in about four hours of interaction, and he states that he has not deliberately read a single line of the Swift code.

He also notes, with some irony, that he does not manually review Sanductor's own Swift. The workflow, not the code, is what he trusts.

How Do You Supervise Agents From Your iPhone?

Sanductor has its own iOS client, and it works over SSH with no hosted relay. McQuaid moved to it from Moshi, an iOS SSH client, because he wanted remote workflows without trusting a third-party service to hold that level of access. The product page states it plainly: no Sanductor account, subscription, or hosted relay exists or is planned, and you should not trust a relay to have this level of access.

The iPhone app is not on the App Store. You build it from source: run the bootstrap and install scripts in a source checkout, then build the Sanductor-iOS target in Xcode with your own signing team. It needs iOS 26 or later.

That is a real barrier for most people, and it is worth stating plainly. The phone client is a power feature for someone who already builds from source, not a download for everyone.

Setup is key-based, not password-based. You copy the phone's public key from iPhone Settings to the Mac clipboard, install it for the sandvault user, and re-run the sandbox build. Access is revoked by deleting that key file and re-running the build.

You add a Match User block for the sandbox user to the SSH daemon configuration, enable Remote Login for that user, and enter the Mac's address in the app. Use port 22 on a local network or a VPN. For public access, forward a different external router port to the Mac's port 22, with key-only authentication, and verify the host key against the Mac's own key fingerprint.

A changed key must be explicitly replaced in Settings.

The phone is a supervisor, not a second Mac. You check status, read what agents did, and start tasks through Shortcuts and Siri. The heavy work still happens on the Mac, in the worktrees, under the sandbox user.

Mosh keeps the session usable when the phone's connection drops and reconnects. The design stays consistent with the desktop app: your machine, your keys, no middleman.

Sanductor vs kosa8: What Is Actually Different?

No source fetched for this article compares Sanductor with kosa8 directly, so this section does not pretend to be a head-to-head test. What the sources do establish is the framing, and the framing is enough to place the two tools. If you want the full kosa8 picture first, the guide on what kosa8 is covers its sealed microVM model in detail.

Kosa8's own sandbox map, published October 31, 2026, sorts agent sandboxes by boundary and by location. Boundaries are container, user-space kernel, microVM, or full virtual machine. Locations are local, managed cloud, or your own cloud.

Sanductor is not mentioned anywhere in that map. Neither is Render Sandboxes. The map is still useful, because it gives names to the two different answers: Sanductor is a local, user-isolation answer, and kosa8 is a local, microVM answer.

The difference is the strength of the wall. Sanductor separates the agent by macOS user: same machine, same kernel, different account, different home directory. Kosa8 gives each agent a sealed microVM with its own kernel, one workspace folder, and a network closed except for an allow-list, with API keys held on the host behind an egress broker and checkpoints in about 0.7 seconds.

A microVM is a stronger wall than a user account. A user account is a lighter wall than a microVM, with no virtualisation overhead and no second kernel to boot.

Both tools agree on the credential rule, which is the more important point. Kosa8 keeps API keys on the host behind an egress broker. Sanductor keeps GitHub credentials on the main user and never shows them to the agent.

Docker Sandboxes, another local option in the kosa8 map, does the same thing differently again: it denies outbound TCP by default through a host-side proxy that swaps a sentinel value for the real API key. Three tools, three walls, one rule: the agent never holds the real key.

Which wall you need depends on what you fear. If you fear an agent deleting the wrong file or reading your SSH keys by accident, user separation plus review is a proportionate answer. If you fear an agent running genuinely untrusted code, a microVM with its own kernel is the stronger answer, and the community guide cited earlier says the same thing about user separation: it protects against accidental breakage, not malicious software.

Sanductor's author chose the lighter wall deliberately, because he wanted native speed and no virtualisation overhead. That is a trade-off, not a flaw, but it is a trade-off you should choose with your eyes open.

Sanductor vs Cloud Sandboxes: Local or Hosted?

The other choice is where the sandbox lives. Sanductor runs on your Mac. Cloud sandboxes run on vendor infrastructure: the kosa8 map lists Cloudflare Sandbox SDK, Daytona, E2B, Modal, Northflank, Runloop, and Vercel Sandbox as cloud services, and Docker Sandboxes as a tool that runs locally or in Docker-managed cloud.

If the cloud model is new to you, the guide to cloud hosting explains how rented infrastructure differs from a machine you own.

McQuaid's reason for staying local is trust, not price. He writes that he wanted remote workflows without trusting a third-party service, and that he could not at all trust a third-party service to run his workflows remotely. A cloud sandbox means your code, your prompts, and your agent sessions run on someone else's computers.

A local sandbox means they run on yours. That is the whole argument, and it is a reasonable one for someone who maintains Homebrew and reviews other people's pull requests for a living.

Price follows the same split. Sanductor is free and open source, and the agents are the only paid part. Cloud sandboxes are services, and services charge: Docker Sandboxes is free locally and pay-as-you-go in the cloud, per the kosa8 map.

Local costs you a Mac that is switched on. Cloud costs you a bill that grows with usage. Neither is free in the full sense, but they charge different things.

Render Sandboxes was named in the queue as a cloud sibling to this topic, but no source about it was fetched for this article, so it is not described here. That is a gap, not a verdict. What the sources do support is the general rule: local sandboxes trade isolation strength for control and zero service cost, and cloud sandboxes trade control and cost for stronger isolation and no local machine.

Sanductor sits firmly on the local side of that line, and it does not pretend otherwise.

What Are Sanductor's Limits?

Sanductor is young, small, and personal, and its own documentation says so. The README calls it personal software without support or compatibility guarantees. The repository was created on August 1, 2026.

The blog post that introduced it is dated September 24, 2026, which is 42 days before this article. Fifteen releases in 96 days is fast movement, and fast movement means the version, the features, and the requirements can all change between the time you read this and the time you install it.

The platform limits are hard limits. It is macOS only, Apple silicon only, and macOS 26 or later. There is no Windows version, no Linux version, and no Intel Mac version.

The iOS client is built from source, not downloaded from the App Store. The agents are Codex and Claude Code only, so a Gemini user gets nothing from Sanductor itself, even though upstream Sandvault supports Gemini. If you work on more than one platform, Sanductor can only ever be your Mac tool.

The adoption numbers are small and should be read as small. Sixty-five stars and 11 forks, with 0 open issues, is a healthy sign for a three-month-old personal project, and it is not evidence of a community. The author says a few coworkers and Homebrew maintainers use it.

No independent review exists, no tutorial exists, and no Hacker News thread about it surfaced in the searches for this article. That does not mean the tool is bad. It means you are early, and early means you test it yourself instead of trusting a crowd.

The remaining limits are practical. Agents can change shared files and upload readable code, so review is not optional. The sandbox user cannot install tools, so you do that yourself first.

The sv command collides with runit, so runit users must resolve that first. The Sandvault fork question is unresolved, and the shared workspace path differs between the two Sandvault READMEs, so check the path in the version you install rather than trusting a path quoted in any article, including this one.

Who Should Try Sanductor, and Who Should Skip It?

Sanductor fits a specific person: a Mac developer who already runs Codex or Claude Code, who works on GitHub projects with pull requests and CI, and who wants agents to do real work without holding the keys to the machine. If you run several agents at once, if you review pull requests all day, and if you like the idea of supervising from your phone over SSH, the app is built for you. The author is that person, and the app shows it.

It does not fit everyone else. If you are on Windows or Linux, it cannot run. If you are on an Intel Mac, it cannot run.

If you need Gemini, it does not list it. If you need a vendor to support you, the README tells you there is no support. If you need to contain genuinely untrusted code, a microVM is the stronger wall, and the earlier sections explain why.

And if you want a finished, polished product with tutorials and a community, this is too early. Come back in a few months and check the release notes.

The fair test is a weekend. Install the cask, build the sandbox user, point it at a small repository, and give one agent one small task. Review the diff the way you would review a colleague's pull request.

If the loop feels natural, keep going. If the setup fights you, the app is young enough that the fight is real information, not a failure on your side. Either way, you will have learned whether local user-isolation sandboxing suits the way you work, and that is a useful answer even if the answer is no.

Sources

All sources below were fetched on November 5, 2026. Sanductor has no independent coverage yet, so this article rests on primary sources: the author's own blog post, his product page, the GitHub repository, and the Homebrew listing. The kosa8 sandbox map and the community sandbox guide are the only secondary sources, and both are cited where their claims appear.

Mike McQuaid, Vibe Coding Developer Productivity Tools, September 24, 2026: https://mikemcquaid.com/vibe-coding-developer-productivity-tools/

Mike McQuaid, Sanductor product page: https://mikemcquaid.com/sanductor/

GitHub, MikeMcQuaid/Sanductor, repository and README, fetched November 5, 2026: https://github.com/MikeMcQuaid/Sanductor

GitHub, MikeMcQuaid/Sanductor releases, latest 1.0.0, fetched November 5, 2026: https://github.com/MikeMcQuaid/Sanductor/releases

GitHub, MikeMcQuaid/Sanductor issues, 0 open, fetched November 5, 2026: https://github.com/MikeMcQuaid/Sanductor/issues

Homebrew Formulae, Sanductor cask, version 1.0.0, fetched November 5, 2026: https://formulae.brew.sh/cask/sanductor

GitHub, webcoyote/sandvault, upstream Sandvault README, fetched November 5, 2026: https://github.com/webcoyote/sandvault

Homebrew Formulae, sandvault formula, version 1.37.0, fetched November 5, 2026: https://formulae.brew.sh/formula/sandvault

herdr, product homepage, fetched November 5, 2026: https://herdr.dev/

kosa8, AI Agent Sandboxes 2026 Map of the Options, October 31, 2026, fetched November 5, 2026: https://kosa8.com/blog/ai-agent-sandboxes-2026-map-of-the-options/

DEV Community, Running a Local Sandboxed macOS Desktop Using VNC and a Restricted User, fetched November 5, 2026: https://dev.to/jlarky/running-a-local-sandboxed-macos-desktop-using-vnc-and-a-restricted-user-38dk

Frequently Asked Questions

Is Sanductor free?

Yes. Sanductor is free and open source under the AGPL-3.0 licence, and its product page states that no Sanductor account, subscription, or hosted relay exists or is planned. The agents it runs, OpenAI Codex and Claude Code, are separate paid products from OpenAI and Anthropic, so you still need an account for whichever agent you use.

Does Sanductor run on Windows or Linux?

No. Sanductor is macOS only, and it needs an Apple silicon Mac running macOS 26 or later. There is no Windows version, no Linux version, and no Intel Mac version.

The sandbox works by creating a second macOS user, which is a macOS feature, so the app cannot be ported to another operating system without becoming a different tool.

Can Sanductor run Google Gemini?

No. Sanductor lists only OpenAI Codex CLI and Claude Code as supported agents. Upstream Sandvault does support Gemini through its sv gemini command, but Sanductor's README does not list it, so do not expect it to work.

If Gemini is your agent, Sanductor is not your tool.

Is Sanductor the same as Sandvault?

No. Sandvault is the sandbox layer: a command line tool that creates the non-admin macOS user and the shared workspace. Sanductor is the agentic IDE built on top of it, with the three-pane window, the worktrees, the review flow, and the iOS client.

Sanductor is also not Sandpack, Sandfort, or sanduk, which are unrelated tools that share a naming theme.

Do agents in Sanductor have access to my GitHub account?

No. Agents can read public repositories, but they have no GitHub credentials, because the gh command line tool is only ever run as your own user. You sign in with gh auth login as yourself, and the agent works from the sandbox account with its own agent login.

Signing and pushing stay under your control, and the app never signs or pushes on its own.