Bromure Gives Codex a Room of Its Own

Bromure Agentic Coding is easiest to understand when you stop treating it as a polished coding app and watch the boundary move.

The Mac app builds a Linux environment, gives that environment a workspace, brings Codex into it, and asks for approval at the moments that matter. The interesting evidence is not the promise of “safe AI coding,” but the observable chain underneath: a local installer and generated base image, a private guest network with a visible proxy, a VM filesystem with separate mounts, Codex authentication and directory trust, approval before writes and commands, and an explicit path for output to leave the VM.

I captured that chain while installing Bromure and using Codex to create a small HTML page. This is a walkthrough of what actually happened, including the parts that still need work.

Start with the installation, not the brochure

The first useful artifact is simple: the app asks macOS to install its command-line component.

macOS presented the app as a notarized, developer-signed installation. That does not prove the sandbox is perfect, but it establishes a much better starting point than running an unidentified binary.

The installation log then showed the environment being assembled:

[init] Downloading Alpine netboot installer…
[init] Allocating 24GB sparse disk…
[init] Booting Alpine installer…

The installer then downloaded the pieces needed to construct the Linux environment. The UI showed a roughly 1.79 GB Ubuntu 24.04 base image being downloaded and expanded.

The base image is part of the product

The installation log made the build process visible:

[init] Downloading Alpine netboot installer…
[init] Allocating 24GB sparse disk…
[init] Booting Alpine installer…
[ac-proxy] listening on 0.0.0.0:52329
[ac-proxy] guest URL = http://192.168.64.1:52329

Inside the installer, the guest received 192.168.64.2 from 192.168.64.1. The proxy logged package and dependency traffic rather than leaving the network boundary as an abstract setting.

The captured run included upstream requests to:

dl-cdn.alpinelinux.org
dl.google.com
registry.npmjs.org
x.ai

That is a useful audit trail. It tells us which hosts were contacted while the image was being prepared. It does not, by itself, prove that every later workspace action is completely offline or that credentials can never be exposed. Those are claims worth testing, not assumptions to repeat.

Bromure also presented a credential-import flow:

The UI described a design where real credential values remain on the Mac and the VM receives substitutes. That is exactly the kind of boundary a security-conscious AI user should validate with a harmless test credential, a deliberately blocked request, and the product’s trace output.

What the VM actually looks like

Once the workspace was running, the terminal showed the mounts instead of hiding them behind a single “sandbox” label.

Here is the important part of the captured output:

/dev/vda2 on / type ext4 (rw,noatime)
/dev/vdb on /home/ubuntu type ext4 (rw,noatime)
bromure-home on /home/ubuntu type virtiofs (rw,relatime)
bromure-meta on /mnt/bromure-meta type virtiofs (ro,relatime)
bromure-outbox on /mnt/bromure-outbox type virtiofs (rw,relatime)

The VM has its own Linux root filesystem. It also has explicit shared mounts for metadata and outbound results. The absence of a shared Mac home folder in this workspace was more informative than a generic privacy statement.

Try this in a Bromure terminal:

That command is not a security certification. It is a reality check. It lets you compare the UI’s promises with the environment the model can actually see.

The workspace configuration is where the policy becomes visible

The workspace I used showed:

Codex: subscription
Guardrails: prompt before write
Prompt-injection scan: off
Shared folders: none

That combination is worth calling out. “Prompt before write” is a clear control: the agent can propose a change, but the user is asked before the filesystem mutation. “Shared folders: none” makes the default boundary easier to reason about. “Prompt-injection scan: off” is equally important because it prevents the screenshot from being mistaken for a fully hardened configuration.

The tradeoff is straightforward: fewer shared folders mean fewer accidental paths into the host, but they also mean more deliberate setup when you want to bring source code or assets into the workspace.

Bringing Codex into the room

Codex offered an interactive browser login and a device-code path for a remote or headless machine.

After authentication, Codex asked whether it should trust the working directory:

That creates a useful sequence of decisions: Bromure creates the workspace, the user authenticates Codex inside it, Codex asks about the directory, and Bromure asks before writes and commands according to the workspace policy.

By the time Codex reached its prompt, the workspace had established the important context: a signed-in coding agent, a trusted project directory, a Linux filesystem, and a user-controlled approval step before changes were made.

A small task with visible approvals

I gave Codex a task that would leave a readable artifact:

The resulting screen showed the green diff and the verification step:

The useful interaction is the sequence, not the page itself:

user prompt
  ↓
Codex explains the proposed change
  ↓
user approves the write
  ↓
file is created in the VM
  ↓
Codex searches the file to verify the result

That is a much more concrete demonstration of agentic coding than a static claim that the model is “contained.”

Commands are approvals too

Next I asked Codex to serve the file locally:

python3 -m http.server 8000 --bind 127.0.0.1

Bromure surfaced a command approval:

Codex then ran curl inside the workspace and reported the server URL:

http://127.0.0.1:8000/bromure-demo.html

This exposed another useful boundary: 127.0.0.1 inside the VM is not automatically 127.0.0.1 on the Mac. A server can be healthy inside the guest and still be unreachable from the host browser unless Bromure publishes the port or the process binds to the guest interface.

That distinction becomes visible because the coding agent is actually running somewhere else.

From an empty app to a working workspace

The first launch is a guided build rather than a blank terminal. Bromure starts with a welcome screen, downloads the Ubuntu base image, and expands it into the environment where the coding session will run.

That gets the workspace from an empty app to a running Linux environment before Codex is asked to do anything.

The control plane is visible before the first prompt

The most useful screenshots are the ones taken before the agent starts coding. Bromure’s credential screen says that the real values stay on the Mac while the VM receives substitutes. Its workspace screen then shows the active policy: Codex is connected through a subscription, writes require approval, prompt-injection scanning is displayed as a setting, and no shared folders are attached.

That is practical evidence of how the app is meant to be used: configure the boundary first, then bring the coding agent into it. The screenshots give the reader something concrete to inspect before they ever see a generated file or a model response.

What Bromure is good for

Bromure is for giving a coding agent a separate Linux workspace instead of letting it work directly in your Mac environment. That makes it useful for trying unfamiliar repositories, building quick prototypes, running generated code, testing packages, and letting Codex work on a project without immediately handing it your home directory.

The appeal is that the separation is visible. In this session, Codex created an HTML file, changed it, served it, and verified it inside the workspace. Bromure showed the VM mounts and paused for approval before the write and before the command. I could see where the work happened and what Codex was asking to do.

That is the demo: give Codex a small job, watch it make the file, approve the server, and open the result. The point is not that Bromure makes every risk disappear. The point is that it gives the agent a room to work in, gives the user a door to control, and makes the handoff between the two visible.

Sources and further reading

• Bromure Agentic Coding
• Bromure website
• Apple Virtualization framework
• OpenAI Codex
• OpenAI Codex CLI

rss facebook x reddit linkedin email follow