# Multi Frontier Desktop > Run or extend the Desktop Code Agents Multi-Frontier workflow. Use when coordinating Codex and Claude Code subscriptions, collaboration phases, checkpoints, recovery, usage meters, or helper admission. - Skill: `builderio/multi-frontier-desktop` (Agent Skill) - Install (CLI): `npx skillmds@latest add builderio/multi-frontier-desktop` - Raw SKILL.md: https://api.skillmd.com/api/skills/builderio/multi-frontier-desktop/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: Builder.io (https://skillmd.com/u/builderio) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/builderio/multi-frontier-desktop --- # Multi-Frontier Desktop ## Rule Multi-Frontier is a Desktop-only, local Code Agents workflow with exactly two subscription-native participants: Codex through ChatGPT and Claude Code through Claude. Electron main owns every privileged operation, durable state transition, provider process, and write lease. The renderer is presentation and command intent only. ## Before a collaboration 1. Connect subscriptions through their own CLI sign-in flow. Use `codex login` for ChatGPT and `claude auth login --claudeai` for Claude. Never ask for, parse, copy, extract, log, or persist OAuth credentials, auth files, Keychain values, or rollout data. 2. Read provider status through the typed Desktop host/preload/IPC operations. Do not call Node, child processes, app-server stdio, or the filesystem from the renderer. 3. Present only provider-reported plan and usage fields. Missing data is “Not reported by provider,” not zero. Codex may show capability-probed live usage and credits. Claude v1 shows connection and plan tier with explicit “Live usage unavailable” when its supported session side channel cannot report it. 4. Treat account identity and provider raw payloads as private. They do not belong in collaboration state, artifacts, transcript metadata, usage snapshots, logs, telemetry, or IPC. Keep renderer cards compact and disclose meter details in an accessible popover. ## Collaboration workflow 1. Start both participants as read-only. They independently produce bounded proposal artifacts. 2. Give each participant the other proposal, the original request, and bounded repository evidence for cross-review. Number findings by consequence. 3. Allow at most one revision per participant per round and retain supersession links; never overwrite an earlier proposal or review. 4. Publish a compact, attributed convergence summary. Stop after three rounds rather than guessing through a material disagreement. 5. Default to an inline explicit **GO**. Per-run auto-continue is permitted only after recorded agreement on a reversible path. It never disables escalation for scope or intent ambiguity, destructive work, security or privacy impact, external communication, meaningful cost expansion, or irreversible data or architecture decisions. 6. Grant `workspace_write` only to the current driver generation after GO. The other participant remains read-only. Do not rely on prompts for this rule. 7. At a stable driver turn or material-diff boundary, revoke the write lease, record an immutable bounded checkpoint, and let the watchdog review that checkpoint rather than a moving worktree. Record each finding as addressed, rejected with rationale, or deferred with rationale. 8. On cancellation, crash, quit, or restart, stop owned children, revoke the lease, persist a paused recovery record, and require an explicit newly fenced continuation. Never automatically resume native execution after recovery. ## Helper and quota policy - Use capability-probed inexpensive models for read-only research, test analysis, and review only. Record requested and effective model for every helper launch; omission must not inherit an expensive frontier model. - Pass helpers bounded prompts and artifacts, not raw transcripts. Enforce task and delegation-depth caps. - An editing helper needs a formal driver-lease handoff after the original driver is suspended. Two workspace-write processes are never allowed. - Usage is advisory. Warn before optional work near a reported limit and stop launching optional helpers/watchdog work at the configured threshold. Let a running provider report its own authoritative limit error. ## Persistence and UI - Preserve existing single-agent Code behavior. Multi-Frontier state is versioned, additive, file-backed local Code-run data with atomic parent updates and bounded append-only events/artifacts. - Persist safe identifiers, phase, roles, lease generation, approval, checkpoint/proposal/review references, opaque session references, and bounded summaries only. Never persist full prompts, diffs, unbounded provider output, credentials, account identifiers, or raw app-server events. - Keep the Code Agents surface calm and progressively disclosed: add the mode, participants, and per-run auto-continue choice to the existing composer; show phase as a subtle status line and roles as two small badges; keep proposal, review, and checkpoint evidence compact and collapsed by default; put rare pause, cancel, and role-swap controls in the existing run menu where possible. Use accessible status announcements and the shared composer stack instead of a bespoke prompt field. ## Verification - Exercise the typed IPC boundary with hostile renderer inputs; renderer state must not become command authority. - Prove stale driver generations, duplicate events, and concurrent write turns are rejected. - Prove cancellation and checkpoint transitions cannot leave a write-capable child running. - Verify recovery is persistence-only until explicit user continuation. - Run focused Desktop tests/typecheck, format modified files, and record packaged-runner and installed-app evidence in `MULTI_FRONTIER_PROOF.md`. ## Don't - Do not add hosted SQL, hosted parent-thread orchestration, Keychain/OAuth scraping, or undocumented provider usage endpoints to Desktop v1. Keep an API-key path explicitly separate; never silently substitute it for a subscription runtime. - Do not display a missing provider meter as zero or fabricate freshness, remaining tokens, dollars, or a plan limit. - Do not use a modal as the normal convergence path, let a watchdog inspect a moving worktree, or permit a write-capable helper without a lease handoff. ## Related Skills - `harness-agents` — native harness boundaries. - `security` — credential and sensitive-data handling. - `onboarding` — user-initiated provider connection flows. - `frontend-design` and `shadcn-ui` — compact, accessible Desktop UI.