A Public Launcher for AI CLI Isolation and Durable FIFO Delivery
Sole designer, implementer, and operator
2026-04-01 — present
Built project-scoped AI CLI isolation, then replaced a long-held shared delivery lock with durable submission and a destination-ordered FIFO queue. Integrated OMP through an upstream extension, configuration overlay, and thin adapter rather than a local fork, with verified runtime, print, and signal boundaries.
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
Integration delivery
Real jobs from two pools: attempt 1, exit 0, DELIVERED
Destination FIFO · same-ID duplicates · non-cancelling wait timeout
Before: Shared-lock waits failed at 600 and 3600 seconds
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.
Holding a shared lock through verification, push, and remote readback caused delivery waits to fail at both 600 and 3600 seconds; increasing the timeout did not solve it.
Separated durable enqueue from completion waiting, with destination FIFO, idempotent submission, and worker/test budgets. Froze the patch, manifest, binding, and runtime snapshot at intake; recovery after a crash following push checks durable publication intent and remote history before retrying.
Real jobs from two pools started in FIFO order for the same destination and both completed on attempt 1 with exit 0 and DELIVERED status. Duplicate submission returned the same ID, and a wait timeout left the job queued.
Source-drift admission in the local OMP fork terminated active sessions, while an isolated HOME disrupted hook policy and authentication propagation.
Removed local patches in favor of an upstream trusted extension, configuration overlay, and thin adapter. Corrected account HOME for hook children and authentication propagation for the shell, then verified URL-read policy, policy checks before print provider calls, and PTY FD, PID, and signal handling.
On the selected v0.77.7 snapshot, real native print denials made zero provider calls and exited 2; the allowed control matched the receipt PID. Ctrl-C exited the shell with 130 and left no native process. Full global DB SSOT and upstream MCP/LSP activation are outside the completed scope.
Operating limits
Project Description
harness-launcher treats each registered project path as a trust boundary and refuses to start an AI CLI when ownership is unresolved. Its integration queue separates acceptance from completion, starts jobs for the same destination in FIFO order across pools, and limits worker and test concurrency. The OMP adapter enforces existing policy on the upstream runtime. A separate public contract demo reproduces isolation and source SHA-256 verification; private documents, company data, and production indexes are excluded from public evidence.
Highlights
- Canonical project paths isolate runtimes; outside paths, symlink escapes, and ambiguous ownership stop before launch
- Durable acceptance, destination FIFO, idempotency, and worker/test budgets replace the long-held shared lock
- Real delivery from two pools, same-ID duplicate submission, and non-cancelling wait timeout verified
- OMP upstream integration with real print and Ctrl-C checks, traced through PR #146 and v0.77.7
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.
- ▶Separates durable acceptance from completion waiting instead of increasing timeouts. Start order for the same destination holds across pools, while separate budgets limit worker and test concurrency.
- ▶Uses an upstream trusted extension, overlay, and thin adapter rather than maintaining a local OMP fork. MCP/LSP remain disabled without the required upstream APIs.
Lessons Learned
- •Select profiles by canonical path ownership, not name inference.
- •Separate acceptance from completion so a caller's timeout does not cancel accepted work.
- •Upstream integration needs more than configuration compatibility: verify actual HOME, authentication, input, and termination signals.
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.