@agfpd/iapeer 0.4.4 → 0.4.6

package/README.md

@@ -21,6 +21,13 @@ router daemon   — always on; finds the recipient, checks liveness, delivers
 recipient peer  — asleep? the daemon wakes it and delivers on wake
 ```
 
+## What makes it different
+
+- **Real interactive CLI sessions, not headless one-shots.** Each AI peer is a full Claude Code or Codex CLI session, not a disposable `claude -p` / `codex exec` call (as of 2026-06-15, `claude -p` no longer counts against the subscription's main usage limits).
+- **Warm-on-demand lifecycle.** A live session answers fast; after about an hour idle the daemon closes it; the next message brings it back with its context resumed. The message flow drives the lifecycle — not a human's presence.
+- **One identity across runtimes, with one memory.** A peer's `personality` is decoupled from its runtime — the same peer runs on Claude or Codex, switched with a command. By default (set up by `iapeer onboard`) it carries one shared memory (iapeer-memory) keyed to the personality, not the runtime: one personality, one memory, whatever runtime it runs on.
+- **Heterogeneous peers, one protocol.** AI agents, humans (Telegram), and services (timer = cron, watcher = event) are all first-class, addressed the same way over an always-on MCP daemon that exposes exactly one tool, `send_to_peer`.
+
 ## Quick start
 
 Requirements: **macOS** (Linux is on the [Roadmap](#roadmap)) and at least one agent runtime — Claude Code or Codex CLI (each AI peer is a live session of one). The installer handles the rest ([bun](https://bun.sh) and `~/.local/bin` on `PATH`).
@@ -78,22 +85,15 @@ Agents reach each other with `send_to_peer`; you can also message any peer over
 
 ## Bypass Permissions mode
 
-⚠️ **iapeer runs your Claude and Codex peers in bypass-permissions / no-sandbox mode — they execute tools (shell, file edits, network) without asking you to approve each action.** This is by design: a peer is a background, headless session with no human watching its terminal, so there is no one to answer a per-tool permission prompt. The launcher therefore starts Claude with `--dangerously-skip-permissions` and Codex with `--dangerously-bypass-approvals-and-sandbox`, and **auto-accepts the one-time "accept bypass mode" screen on your behalf** the first time a peer boots on a fresh machine.
+⚠️ **iapeer runs your Claude and Codex peers in bypass-permissions / no-sandbox mode — they execute tools (shell commands, file edits, network calls) without asking you to approve each action.** This is by design: a peer is a background, headless session with no human watching its terminal, so there is no one to answer a per-tool permission prompt. The launcher starts Claude with `--dangerously-skip-permissions` and Codex with `--dangerously-bypass-approvals-and-sandbox`, and **auto-accepts the one-time "accept bypass mode" screen on your behalf** the first time a peer boots on a fresh machine.
 
 What this means for you, stated plainly:
 
-- A peer can run any command its runtime can run — read and write files across your home dir, install software, make network calls — with **no confirmation step**. There is no sandbox between an agent and your machine.
-- You are trusting the model's judgement (and the doctrine/instructions you give each peer) the same way you would trust a developer with a shell on your account.
-- iapeer does **not** silently weaken your own interactive `claude`/`codex` setup: the bypass acceptance is recorded per peer in the agent's own config, and the project-MCP pre-approval is written **project-locally** (under the peer's folder), never to your global user settings.
+- A peer can run any command its runtime can run — read and write files anywhere in your home directory, install software, make network calls — with **no confirmation step**. There is no sandbox between an agent and your machine.
+- You are trusting the model's judgment, and the doctrine you give each peer, the same way you would trust a developer with a shell on your account.
+- iapeer does **not** silently weaken your own interactive `claude` / `codex` setup. The bypass acceptance is recorded per peer, in that agent's own config; the project-MCP pre-approval is written **project-locally**, under the peer's folder — never to your global user settings.
 
-Run iapeer on a host you control, give peers only the access they need, and treat a peer's instructions as security-relevant. `iapeer onboard` states this at setup; it is repeated here so the trade-off is explicit before you create your first agent. Details on every first-run dialog: [docs/07 — Install & update](docs/07-install-and-update.md#first-run-dialogs-on-a-clean-machine).
-
-## What makes it different
-
-- **Real interactive CLI sessions, not headless one-shots.** Each AI peer is a full Claude Code or Codex CLI session, not a disposable `claude -p` / `codex exec` call (as of 2026-06-15, `claude -p` no longer counts against the subscription's main usage limits).
-- **Warm-on-demand lifecycle.** A live session answers fast; after about an hour idle the daemon closes it; the next message brings it back with its context resumed. The message flow drives the lifecycle — not a human's presence.
-- **One identity across runtimes, with one memory.** A peer's `personality` is decoupled from its runtime — the same peer runs on Claude or Codex, switched with a command. By default (set up by `iapeer onboard`) it carries one shared memory (iapeer-memory) keyed to the personality, not the runtime: one personality, one memory, whatever runtime it runs on.
-- **Heterogeneous peers, one protocol.** AI agents, humans (Telegram), and services (timer = cron, watcher = event) are all first-class, addressed the same way over an always-on MCP daemon that exposes exactly one tool, `send_to_peer`.
+Run iapeer on a host you control, give each peer only the access it needs, and treat a peer's instructions as security-relevant. `iapeer onboard` states this at setup; it's repeated here so the trade-off is explicit before you create your first agent. Details on every first-run dialog: [docs/07 — Install & update](docs/07-install-and-update.md#first-run-dialogs-on-a-clean-machine).
 
 ## Documentation
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agfpd/iapeer",
-  "version": "0.4.4",
+  "version": "0.4.6",
   "description": "Foundation core for the iapeer multi-agent ecosystem: identity, registry, storage, codec.",
   "license": "Apache-2.0",
   "author": "agfpd",

package/src/cli/index.ts

@@ -37,10 +37,10 @@ import {
   isEphemeralPeer,
   isStopped,
   killSession,
-  lastActiveRuntime,
   loadLifecycleConfig,
   purgeIdentityState,
   removeSessionState,
+  resolvePeerRuntime,
   setEphemeralArmed,
   setFreshNext,
   setIdleReaped,
@@ -518,7 +518,10 @@ export async function newPeer(
     }
   }
   if (runtime && !isRuntime(runtime)) throw new Error(`invalid runtime "${runtime}"`)
-  const rt: Runtime = (runtime as Runtime | undefined) ?? peer.runtime
+  // Omitted runtime resolves IDENTICALLY to `attach` (resolvePeerRuntime): default_runtime
+  // anchored, sole-live refinement — so `iapeer new <peer>` and `iapeer attach <peer>` never
+  // target different runtimes (the "new had no effect, attach resurrected the other" footgun).
+  const rt: Runtime = (runtime as Runtime | undefined) ?? resolvePeerRuntime(peer, cfg)
   if (!peer.runtimes.includes(rt)) {
     return {
       personality,
@@ -638,7 +641,9 @@ export async function compactPeer(
     return { personality, runtime: r.value.controlled.runtime, action: 'compacted', woke: false }
   }
 
-  const rt: Runtime = (runtime as Runtime | undefined) ?? lastActiveRuntime(peer, cfg) ?? peer.runtime
+  // Asleep branch: omitted runtime resolves like new/attach (resolvePeerRuntime) — consistent
+  // default_runtime anchoring instead of the old hidden last-active-by-mtime.
+  const rt: Runtime = (runtime as Runtime | undefined) ?? resolvePeerRuntime(peer, cfg)
   if (!peer.runtimes.includes(rt)) {
     return {
       personality,
@@ -1396,8 +1401,34 @@ export async function runCli(argv: string[], env: NodeJS.ProcessEnv = process.en
           env,
           warn: m => errOut(`warn: ${m}\n`),
         })
+        // FU5 parity with `create`: a peer's `runtimes` must list EVERY installed agentic
+        // runtime (the default is just one of them), so `iapeer <other-runtime>` works
+        // without a manual add-runtime. initPeer resolves only the PRIMARY (cwd markers /
+        // --runtime); declare the OTHER installed agentic runtime(s) too — otherwise the
+        // registry the launch dispatch reads (folderLaunch → resolveWakeRuntime) lists the
+        // primary only and `iapeer codex` fails "not declared" on a both-installed host.
+        // addRuntime is capability-only (runs the runtime birth chain, reindexes the
+        // registry from locals, NEVER flips the default); skip for an infra primary.
+        const addedRuntimes: Runtime[] = []
+        if (!isInfraRuntime(r.runtime)) {
+          const { isRuntimeInstalled } = await import('../init/index.ts')
+          const { secondaryRuntimes } = await import('../create/index.ts')
+          const installed = (['claude', 'codex'] as Runtime[]).filter(rt => isRuntimeInstalled(rt, env))
+          for (const rt of secondaryRuntimes(r.runtime, installed)) {
+            try {
+              const outcomes = await addRuntime(rt, { peer: r.personality, env })
+              const o = outcomes.find(x => x.personality === r.personality)
+              if (o && (o.action === 'added' || o.action === 'already')) addedRuntimes.push(rt)
+              else errOut(`warn: could not add runtime "${rt}": ${o?.detail ?? o?.action ?? 'failed'}\n`)
+            } catch (e) {
+              errOut(`warn: could not add runtime "${rt}": ${e instanceof Error ? e.message : String(e)}\n`)
+            }
+          }
+        }
+        const allRuntimes = [r.runtime, ...addedRuntimes]
         out(
-          `initialized "${r.personality}" (${r.runtime}); mcp: ${r.mcpConfigPaths.join(', ') || r.codexMcpConfigPath || 'none'}` +
+          `initialized "${r.personality}" (default: ${r.runtime}; runtimes: ${allRuntimes.join(', ')}); ` +
+            `mcp: ${r.mcpConfigPaths.join(', ') || r.codexMcpConfigPath || 'none'}` +
             `${r.bootstrapped ? `; bootstrap: ${r.bootstrapped.state}` : ''}\n`,
         )
         return 0

package/src/lifecycle/index.ts

@@ -1552,9 +1552,11 @@ export async function folderLaunch(opts: FolderLaunchOptions): Promise<WakeResul
 }
 
 /**
- * The runtime with the freshest transcript activity for a peer (contract: attach
- * resolves the runtime by last-active transcript-mtime, NOT the profile default).
- * undefined when no runtime has any activity (a never-run peer).
+ * The runtime with the freshest transcript activity for a peer. undefined when no
+ * runtime has any activity (a never-run peer). NOTE: this is NO LONGER the attach
+ * default — operator runtime resolution moved to `resolvePeerRuntime` (default_runtime
+ * anchored) because last-active-by-mtime is hidden state and unreliable for codex
+ * (rollout flushed only on a real turn). Kept as a diagnostic / `list` helper.
  */
 export function lastActiveRuntime(peer: PeerRecord, cfg: LifecycleConfig): Runtime | undefined {
   let best: Runtime | undefined
@@ -1573,6 +1575,46 @@ export function lastActiveRuntime(peer: PeerRecord, cfg: LifecycleConfig): Runti
   return best
 }
 
+/** Runtimes of `peer` whose session is LIVE right now (lifecycle-local liveness,
+ *  same `sessionAlive` predicate the wake/attach paths use). */
+function liveRuntimesOf(peer: PeerRecord, cfg: LifecycleConfig): Runtime[] {
+  return peer.runtimes.filter(rt =>
+    sessionAlive(buildSocketPath(rt, peer.personality, cfg.sockDir), buildProcessAddress(rt, peer.personality)),
+  )
+}
+
+/**
+ * The SINGLE runtime an operator verb (new / attach / compact) acts on when the
+ * runtime arg is OMITTED, for a peer that may declare several. PREDICTABLE by
+ * construction and IDENTICAL across those verbs — this is the fix for the
+ * multi-runtime footgun where `new` defaulted to `default_runtime` while `attach`
+ * defaulted to last-active-by-mtime, so `iapeer new <peer>` freshed one runtime
+ * while `iapeer attach <peer>` resurrected the other ("new had no effect, attach
+ * came up on the old session").
+ *
+ * Precedence (never refuses — the naive flow must self-resolve, no explicit arg):
+ *   1. sole declared runtime → it.
+ *   2. `default_runtime` is LIVE → `default_runtime` (the configured anchor AND the
+ *      obvious running target).
+ *   3. exactly ONE other runtime is live (default dead) → that live one.
+ *   4. otherwise (nothing live, or 2+ live without the default) → `default_runtime`.
+ *
+ * The peer's runtime is governed by its CONFIGURABLE `default_runtime` (the
+ * documented `iapeer default-runtime` lever), NOT by which transcript was touched
+ * last — last-active-by-mtime is hidden state and unreliable for codex (its rollout
+ * file is flushed only on a real model turn, so a just-spawned fresh codex session
+ * reads as "older" than a stale one). To make `iapeer new/attach <peer>` (no runtime
+ * arg) resolve to codex, set the peer's default to codex once; per-command runtime
+ * args remain the explicit override.
+ */
+export function resolvePeerRuntime(peer: PeerRecord, cfg: LifecycleConfig): Runtime {
+  if (peer.runtimes.length === 1) return peer.runtimes[0]
+  const live = liveRuntimesOf(peer, cfg)
+  if (live.includes(peer.runtime)) return peer.runtime
+  if (live.length === 1) return live[0]
+  return peer.runtime
+}
+
 export interface AttachOptions {
   personality: string
   runtime?: string
@@ -1586,10 +1628,11 @@ export type AttachResult =
 /**
  * `iapeer attach <peer> [runtime]` — ensure the peer is live, then hand back the
  * socket/identity for the caller to `tmux attach`. ALWAYS RESUME (contract: attach
- * never starts fresh). Runtime: explicit arg, else the LAST-ACTIVE runtime by
- * transcript-mtime (not the profile default), else the profile default. A warm-live
- * session is attached directly; a warm-asleep one is woken with --resume first
- * (fail-loud if there is nothing to resume — a never-run peer must be folder-launched).
+ * never starts fresh). Runtime: explicit arg, else `resolvePeerRuntime` (the SAME
+ * resolver `new`/`compact` use — default_runtime anchored with a sole-live
+ * refinement), so attach and new never disagree on which runtime "peer" means. A
+ * warm-live session is attached directly; a warm-asleep one is woken with --resume
+ * first (fail-loud if there is nothing to resume — a never-run peer must be folder-launched).
  */
 export async function attachPeer(opts: AttachOptions): Promise<AttachResult> {
   const env = opts.env ?? process.env
@@ -1598,8 +1641,10 @@ export async function attachPeer(opts: AttachOptions): Promise<AttachResult> {
   if (!peer) return { ok: false, reason: `peer "${opts.personality}" is not registered` }
   const runtimeResult = resolveWakeRuntime(opts.runtime, peer)
   if (opts.runtime && !runtimeResult.ok) return { ok: false, reason: runtimeResult.error.message }
-  // last-active (by mtime) wins over the profile default when no runtime is given.
-  const runtime = opts.runtime ?? lastActiveRuntime(peer, cfg) ?? peer.runtime
+  // Omitted runtime resolves IDENTICALLY to `new`/`compact` (resolvePeerRuntime):
+  // default_runtime anchored, sole-live refinement, never hidden last-active — so
+  // `iapeer attach <peer>` and `iapeer new <peer>` never disagree on the runtime.
+  const runtime = opts.runtime ?? resolvePeerRuntime(peer, cfg)
   const identity = buildProcessAddress(runtime, opts.personality)
   const sock = buildSocketPath(runtime, opts.personality, cfg.sockDir)
   if (sessionAlive(sock, identity)) return { ok: true, identity, socketPath: sock, woke: false, runtime }