Cloister 0.1.0

Cloister 0.1.0

Cloister 0.1.0 is the first public release of a terminal-first development
environment for running Codex and Claude Code in Linux ARM64 guests managed by
Apple's container CLI. It keeps the selected workspace, agent state, network
policy, and optional host-command access explicit in a versioned Profile.

Highlights

• Run Codex and Claude Code through the same Profile V6 contract and Apple
  container command planner.
• Create a Profile interactively with cloister init. Runtime startup, image
  pulls, and the required localhost DNS mapping remain separate, confirmed
  operations, and an existing Profile path is never overwritten.
• Inspect Profile, proxy, host-command, runtime, image, and DNS readiness
  without changing state with cloister check.
• Preserve Codex and Claude state in separate owner-only Cloister directories,
  or keep agent state isolated inside an ephemeral guest.
• Expose explicitly allowlisted macOS commands through the authenticated
  cloister_host MCP server and its canonical Host Exec skill.
• Discover host commands, start work, stream incremental output, inspect long
  executions, and cancel complete process groups through host.list_commands,
  host.exec, host.exec_status, and host.exec_cancel.
• Record bounded, owner-only Host Exec lifecycle metadata without persisting
  raw arguments, output, environment values, bearer tokens, or credentials.

Installation

Cloister 0.1.x is available from the official Homebrew tap. The Formula builds
the CLI from the exact release source and installs Apple container as a
runtime dependency. It does not start the runtime, create a Profile, or pull
the guest image.

brew install yi427/tap/cloister

Alternatively, compile directly from the exact Git tag:

cargo install --locked \
  --git https://github.com/yi427/Cloister.git \
  --tag v0.1.0 \
  cloister

The CLI and guest image form one release pair:

CLI:   v0.1.0
Image: ghcr.io/yi427/cloister:0.1.0

The image is published for Linux ARM64. It runs as a non-root user and pins the
following primary tools:

Tool	Version
Node.js	24.18.0
Rust	1.97.1
Codex	0.146.0
Claude Code	2.1.220

Security boundary

Cloister reduces ambient host access, but it does not make every exposed
capability safe:

• /workspace is a live read-write bind mount. Guest writes, modifications,
  and deletions affect the selected host project directly.
• Apple container's default network may reach the internet. A named or default
  network is not an egress firewall.
• Host Exec is an explicit escape hatch. An allowed executable runs with the
  macOS permissions and complete inherited environment of the user who started
  Cloister.
• Profile V6 supports arguments = "any". Interpreters and build tools can
  therefore provide broad host execution even when the executable allowlist is
  narrow.
• Agent approval prompts are interaction policy, not a security boundary. A
  guest process with the ephemeral bridge token can call enabled tools, while
  the server still enforces the immutable Profile allowlist.
• Shared agent-state directories contain credentials, settings, history, and
  sessions and must be treated as secrets.
• Audit logs are observational rather than tamper-proof because a sufficiently
  powerful allowed host command may be able to alter them.

Cloister does not silently mount the host's existing Codex or Claude
directories, credential directories, or privileged sockets.

Read the full
security model
and accepted
architecture decisions
before enabling Host Exec for sensitive work.

Requirements and known limitations

• Apple silicon Mac with Apple container 1.2 or newer.
• No Intel Mac, Linux-host, Docker, or general-purpose container-runtime
  support.
• No automatic migration from an incompatible Profile schema; 0.1.0 accepts
  Profile V6.
• No argument-level Host Exec restrictions beyond arguments = "any".
• No host-level CPU, memory, filesystem, or network containment for Host Exec.
• Running Host Exec jobs and captured output do not survive bridge shutdown.
• The default Host MCP port is 17834; another port must be selected manually
  when it is already in use.
• No GUI, prebuilt standalone CLI binary, or floating latest image tag.

First run

cloister init
cloister check

cd /path/to/project
cloister codex
# or
cloister claude

Review the generated Profile before launching an agent, especially the
workspace, proxy mode, shared-state choice, and Host Exec allowlist.

Release verification

The release procedure requires the local staged-snapshot checks and GitHub
Verify workflow to pass, anonymous access to the exact Linux ARM64 image,
installation from the immutable v0.1.0 tag, and end-to-end smoke tests for
init, check, Codex, Claude, Host Exec, cancellation, and audit logging.

The exact release image is immutable. Cloister does not publish latest; a
defective release is replaced by a new patch version rather than by moving the
0.1.0 tag.