A Public Launcher for Isolated, Verified AI CLI Runtimes
Sole designer, implementer, and operator
2026-04-01 — present
A public launcher that isolates global Claude Code, Codex, and Kiro state into project-scoped boundaries and blocks invalid workspaces or configuration drift before startup.
Verified outcomes
Runtime isolation
Runtime homes per registered project
Sessions, skills, MCP tools, and policy stay boundary-scoped
Before: Projects shared global CLI state
Boundary resolution
One owning boundary from the canonical path
Outside, escaped, or ambiguous paths stop before AI CLI startup
Before: Risk of profile inference from names or remotes
Public verification
Public launcher + contract demo + CI
Core contracts and failure behavior reproduce without login
Before: Evidence depended on a private environment
Profile boundaries and launch verification
The launcher canonicalizes the workspace, scans the profile registry, and selects the longest matching boundary. No match, a tie, or a symlink escape aborts before launch.
← Scroll horizontally to view the full flow →
Launch and failure-blocking flow
Boundary resolution, fingerprint-based regeneration, and configuration/source verification all terminate before the AI CLI starts when a gate fails.
← Scroll horizontally to view the full flow →
Problem Solving
Sharing one global AI CLI home across projects could mix sessions, tools, and rules across trust boundaries.
Generated Codex and Kiro runtime homes per registered project and routed profile commands and harness-exec through the same execution policy.
Runtime state stays project-scoped, with installation, profile, and runtime behavior verified in the public repository suite.
A workspace manager that guessed profiles from names or remotes could start an agent with the wrong tools and permissions.
Made harness-auto canonicalize the current path and select only the single most-specific registered boundary, rejecting outside paths, symlink escapes, and equally specific duplicates.
Profile selection is based on path ownership rather than inference, and no AI CLI starts when ownership is unresolved.
A private operating environment alone did not let visitors independently verify profile isolation and source-verification contracts.
Linked the public harness-launcher implementation and tests to a separate public contract demo. The demo checks profile uniqueness, path escape, source SHA-256 drift, and relationship integrity with the standard library.
The core boundaries and failure behavior are reproducible from README, source, and CI without login, while private company data and production indexes remain outside public evidence.
Project Description
harness-launcher uses each registered project directory as a trust boundary for runtime homes, skills, MCP tools, and policy. harness-auto canonicalizes the current workspace, selects exactly one boundary, and refuses to launch outside a boundary, through a symlink escape, or across ambiguous registrations. A separate public contract demo reproduces profile registration and candidate-to-source SHA-256 verification without private documents, company data, or production indexes.
Highlights
- Project registration → boundary resolution → isolated runtime preparation → verification → AI CLI startup
- harness-auto selects one owning boundary from the canonical workspace and stops before launch when outside or ambiguous
- Public launcher repository, release, CI, and contract demo provide evidence reproducible without login
- Private documents, company data, and production indexes are excluded from public repositories and portfolio evidence
Tech Decisions
- ▶Uses the canonical project path as the trust boundary instead of inferring from repository names or remotes. Launch is refused unless one most-specific boundary owns the workspace.
- ▶Treats runtime homes as disposable generated outputs rather than editable source. Re-running preparation converges them from project configuration and verification rules.
- ▶Disables source installation and supports Homebrew only because the portable shell installer could not safely eliminate its TOCTOU write boundary.
Lessons Learned
- •Profiles should be selected by canonical path ownership, not name inference.
- •Generated runtimes are disposable outputs rather than source and must be revalidated before startup.
- •Public case-study evidence must be reproducible without login and cannot be replaced by private operating metrics.
Glossary
Core terms are explained before the technical stack so non-specialists can follow the system.
- Harness
- An operating layer that packages AI CLI runtime, tools, policy, and verification into a repeatable path.
- Profile
- One registered project and the execution boundary it owns.
- Runtime home
- A generated project-scoped directory for CLI configuration, sessions, and skills.
- Boundary resolution
- Resolving the one registered project that owns the canonical current path.
- Fail-closed
- Stopping instead of falling back when a boundary or configuration cannot be proven.
- MCP
- A protocol that lets an AI CLI call project tools through a standard interface.
- Contract demo
- A public example that reproduces boundaries, verification, and failure conditions without production data.
- CI
- A verification pipeline that runs tests for every public repository change.