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

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "ours-fleet",
-  "version": "1.0.5",
+  "version": "1.1.0-nightly.2",
   "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.2",
   "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.**
@@ -151,7 +151,7 @@ Build an argument array from the approved choices. Permanent, unattended:
 
 ```sh
 ours-fleet spawn Worker --harness codex --launcher auto \
-  --session <tmux|acp> \
+  --session acp \
   --mission "Own the worker implementation" --cwd /absolute/project \
   --bio-file /tmp/worker-bio.md --persona-file /tmp/worker-persona.md \
   --approval allow --filesystem workspace --unattended deny \
@@ -163,7 +163,7 @@ Permanent, attended — a human will answer its prompts:
 
 ```sh
 ours-fleet spawn Worker --harness codex --launcher auto \
-  --session <tmux|acp> \
+  --session acp \
   --mission "Own the worker implementation" --cwd /absolute/project \
   --bio-file /tmp/worker-bio.md --persona-file /tmp/worker-persona.md \
   --approval ask --filesystem workspace --unattended wait
@@ -190,14 +190,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