@ours.network/fleet-codex 1.0.5 → 1.1.0-nightly.10

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "ours-fleet",
-  "version": "1.0.5",
+  "version": "1.1.0-nightly.10",
   "description": "Spawn, configure, and oversee ours-fleet roles from OpenAI Codex.",
   "author": {
     "name": "Adapt Framework Solutions Ltd",
@@ -9,7 +9,14 @@
   "homepage": "https://github.com/adapt-toolkit/ours-fleet/tree/main/integrations/codex/ours-fleet",
   "repository": "https://github.com/adapt-toolkit/ours-fleet",
   "license": "FSL-1.1-Apache-2.0",
-  "keywords": ["codex", "ours.network", "fleet", "agents", "spawn", "oversight"],
+  "keywords": [
+    "codex",
+    "ours.network",
+    "fleet",
+    "agents",
+    "spawn",
+    "oversight"
+  ],
   "skills": "./skills/",
   "interface": {
     "displayName": "ours.network Fleet",
@@ -17,7 +24,11 @@
     "longDescription": "Create temporary or supervised ours-fleet roles, configure Codex models and permissions, and keep spawned agents healthy from inside Codex.",
     "developerName": "Adapt Framework Solutions Ltd",
     "category": "Productivity",
-    "capabilities": ["Interactive", "Read", "Write"],
+    "capabilities": [
+      "Interactive",
+      "Read",
+      "Write"
+    ],
     "websiteURL": "https://ours.network",
     "defaultPrompt": [
       "Spawn a new Codex fleet agent for this task.",

package/README.md

@@ -1,7 +1,7 @@
 # @ours.network/fleet-codex
 
 Native OpenAI Codex plugin for `ours-fleet`. It adds skills for creating Codex
-fleet roles and overseeing agents in their tmux consoles. The
+fleet roles and overseeing agents through structured sessions. The
 `@ours.network/fleet` CLI performs the actual lifecycle operations.
 
 ## Install

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ours.network/fleet-codex",
-  "version": "1.0.5",
+  "version": "1.1.0-nightly.10",
   "description": "Native Codex plugin for spawning, configuring, and overseeing ours-fleet agents.",
   "type": "module",
   "license": "FSL-1.1-Apache-2.0",
@@ -11,13 +11,32 @@
     "url": "git+https://github.com/adapt-toolkit/ours-fleet.git",
     "directory": "integrations/codex/ours-fleet"
   },
-  "keywords": ["codex", "openai", "plugin", "fleet", "agents", "spawn", "oversight", "ours.network"],
-  "files": [".codex-plugin", "skills", "bin", "README.md", "LICENSE"],
+  "keywords": [
+    "codex",
+    "openai",
+    "plugin",
+    "fleet",
+    "agents",
+    "spawn",
+    "oversight",
+    "ours.network"
+  ],
+  "files": [
+    ".codex-plugin",
+    "skills",
+    "bin",
+    "README.md",
+    "LICENSE"
+  ],
   "bin": {
     "ours-fleet-codex-install": "bin/ours-fleet-codex-install.mjs"
   },
-  "engines": { "node": ">=20" },
-  "publishConfig": { "access": "public" },
+  "engines": {
+    "node": ">=20"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
   "scripts": {
     "test": "node --test"
   }

package/skills/oversee-agents/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oversee-agents
-description: Inspect, monitor, and unstick ours-fleet agents from Codex using their tmux or ACP session controls and supervisor state. Use when the user asks to keep an eye on agents, oversee spawned roles, check agent status, babysit a subagent, resolve a fleet prompt, or when Codex has just spawned a role and should verify its progress.
+description: Inspect, monitor, and unstick ours-fleet agents from Codex using ACP session controls and supervisor state. Use when the user asks to keep an eye on agents, oversee spawned roles, check agent status, babysit a subagent, resolve a fleet prompt, or when Codex has just spawned a role and should verify its progress.
 ---
 
 # Oversee ours-fleet agents
@@ -14,11 +14,10 @@ ours-fleet peek <Name> [lines]
 ours-fleet status <Name>
 ours-fleet logs <Name>
 ours-fleet send <Name> "<text>"
-ours-fleet send <Name> --key <key>
 ```
 
-Text `send`, `peek`, and `attach` work for tmux and ACP. Raw `send --key` is
-tmux-only; use the `/permit` control shown by ACP `attach` for ACP permissions.
+Text `send`, `peek`, and `attach` use the structured ACP session. Use the
+`/permit` control shown by `attach` for permission requests.
 
 ## Establish scope
 

package/skills/spawn-ours-agent/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: spawn-ours-agent
-description: Spawn and configure a new ours-fleet agent from Codex, with a permanent or temporary lifetime and a tmux or ACP session. Use when the user asks to spawn an agent, create a fleet role, start a background agent, delegate work to another Codex session, choose its model, session, or permissions, or create a subagent with its own ours identity and console.
+description: Spawn and configure a new ours-fleet agent from Codex, with a permanent or temporary lifetime and an ACP session. Use when the user asks to spawn an agent, create a fleet role, start a background agent, delegate work to another Codex session, choose its model or permissions, or create a subagent with its own ours identity and console.
 ---
 
 # Spawn an ours-fleet agent
@@ -54,8 +54,8 @@ What this means in practice, on this harness:
 
 | Neutral intent | Native settings | Meets the floor? |
 | --- | --- | --- |
-| `--approval allow --filesystem workspace` | ACP: `agent-full-access` / `never` / `danger-full-access`; tmux: `never` / `workspace-write` | yes |
-| `--approval allow --filesystem read-only` | ACP: `agent-full-access` / `never` / `danger-full-access`; tmux: `never` / `read-only` | ACP yes; tmux no |
+| `--approval allow --filesystem workspace` | `agent-full-access` / `never` / `danger-full-access` | yes |
+| `--approval allow --filesystem read-only` | `agent-full-access` / `never` / `danger-full-access` | yes |
 | `--approval auto` | ACP: `agent` / `on-request` / `workspace-write` | no — `read-state` only |
 | `--approval ask` or legacy `deny` | conservative prompting mode | no — `read-state` only |
 
@@ -96,7 +96,7 @@ Ask only for choices not already supplied:
 
 - **Lifetime:** permanent (supervised, restartable, survives reboot) or
   temporary (detached supervisor, removed on exit/reboot).
-- **Session:** `tmux` or `acp`; both lifetimes support both.
+- **Session:** `acp`; both lifetimes use the shared structured session interface.
 - **Name:** `[A-Za-z0-9_-]+`; confirm it is absent from `ours-fleet config` and
   `ours-fleet ls`.
 - **Mission and working directory.**
@@ -105,20 +105,10 @@ Ask only for choices not already supplied:
 - **Persona:** local operating contract covering mandate, quality bar,
   boundaries, and escalation. Use the writing-agent-bios skill when available.
 - **Coordinator:** optionally announce readiness to an existing ours identity.
-- **Native Codex mail monitoring:** explicitly ask whether to arm it. Pass the
-  legacy `--monitor` consent flag only after a clear yes. This is distinct from
-  fleet YAML `monitor.mode: fleet|native`, which chooses the wake owner.
+- **Brain:** select a declared Brain whose Codex runtime and monitor policy match the request.
 
-Codex-native controls, offered when relevant:
-
-- model: launcher default or `--model <id>`
-- native approval: `--permission-mode untrusted|on-request|never`
-- native sandbox: `--sandbox read-only|workspace-write|danger-full-access`
-- launcher: `auto` (preferred), `ours-codex`, or `codex`
-- profile: `--profile <name>`
-- search: `--search`
-- arbitrary config: repeatable `--codex-config key=value`
-- additional writable roots: repeatable `--add-dir <path>`
+Codex-native model, reasoning, sandbox, launcher, profile, search, arbitrary config,
+and additional writable roots are Brain-owned and are never separate spawn flags.
 
 ## 5. Materialize approved profile text
 
@@ -150,10 +140,8 @@ cannot cross.
 Build an argument array from the approved choices. Permanent, unattended:
 
 ```sh
-ours-fleet spawn Worker --harness codex --launcher auto \
-  --session <tmux|acp> \
-  --mission "Own the worker implementation" --cwd /absolute/project \
-  --bio-file /tmp/worker-bio.md --persona-file /tmp/worker-persona.md \
+ours-fleet spawn Worker --brain CodexWorker --role Worker \
+  --cwd /absolute/project \
   --approval allow --filesystem workspace --unattended deny \
   --isolation-file /tmp/worker-isolation.yaml \
   --coordinator Coordinator
@@ -162,17 +150,12 @@ ours-fleet spawn Worker --harness codex --launcher auto \
 Permanent, attended — a human will answer its prompts:
 
 ```sh
-ours-fleet spawn Worker --harness codex --launcher auto \
-  --session <tmux|acp> \
-  --mission "Own the worker implementation" --cwd /absolute/project \
-  --bio-file /tmp/worker-bio.md --persona-file /tmp/worker-persona.md \
+ours-fleet spawn Worker --brain CodexWorker --role Worker \
+  --cwd /absolute/project \
   --approval ask --filesystem workspace --unattended wait
 ```
 
-Add `--temp` for a temporary role; it can also use `--session acp`.
-Pass the legacy `--monitor` flag only after consent to arm Codex's native
-monitor. It does not select the wake owner; `monitor.mode` does that in YAML.
-Pass model, profile, search, config, and additional directories exactly as
+Add `--temp` for a temporary role. Pass Brain and Role selections exactly as
 approved. Do not persist secrets in `--codex-config` or fleet YAML; use the
 role's `env` configuration for environment-based credentials.
 
@@ -190,14 +173,13 @@ settings it translated to; the floor line lists what the role actually grants,
 or names what is missing. A failure there means the role will silently do less
 than its briefing says — fix the permissions rather than starting it.
 
-For ACP, `status` must report `backend: acp`, `alive: true`, and a running/idle
-readiness. For a temporary tmux role, the pane is authoritative. Confirm that
+`status` must report `backend: acp`, `alive: true`, and a running/idle
+readiness. Confirm that
 Codex loaded its briefing and reached identity binding. First use can display
 Codex authorization prompts for ours MCP tools.
 Surface those prompts to the user; do not grant persistent trust without their
-explicit approval. Use `ours-fleet send <Name> --key <choice>` only for tmux and
-only for the authorization scope the user approved; ACP permissions are answered
-through `ours-fleet attach`.
+explicit approval. Permissions are answered through `ours-fleet attach` and only
+within the authorization scope the user approved.
 
 If monitoring was approved, confirm the console reports `arm_monitor` success.
 Under native Codex, expect the role to surface the `ours-codex` recommendation