@ours.network/fleet-codex 0.1.0

package/.codex-plugin/plugin.json

@@ -0,0 +1,29 @@
+{
+  "name": "ours-fleet",
+  "version": "0.1.0",
+  "description": "Spawn, configure, and oversee ours-fleet roles from OpenAI Codex.",
+  "author": {
+    "name": "Adapt Framework Solutions Ltd",
+    "url": "https://ours.network"
+  },
+  "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"],
+  "skills": "./skills/",
+  "interface": {
+    "displayName": "ours.network Fleet",
+    "shortDescription": "Spawn and oversee persistent Codex agents",
+    "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"],
+    "websiteURL": "https://ours.network",
+    "defaultPrompt": [
+      "Spawn a new Codex fleet agent for this task.",
+      "Show me the status of my fleet roles.",
+      "Keep an eye on the agents I spawned."
+    ],
+    "brandColor": "#6D5EF5"
+  }
+}

package/LICENSE

@@ -0,0 +1,98 @@
+# Functional Source License, Version 1.1, Apache 2.0 Future License
+
+## Abbreviation
+
+FSL-1.1-Apache-2.0
+
+## Notice
+
+Copyright 2026 Adapt Framework Solutions Ltd
+
+## Terms and Conditions
+
+### Licensor ("We")
+
+The party offering the Software under these Terms and Conditions.
+
+### The Software
+
+The "Software" is each version of the software that we make available under
+these Terms and Conditions, as indicated by our inclusion of these Terms and
+Conditions with the Software.
+
+### License Grant
+
+Subject to your compliance with this License Grant and the Patents,
+Redistribution and Trademark clauses below, we hereby grant you the right to use,
+copy, modify, create derivative works, publicly perform, publicly display and
+redistribute the Software for any Permitted Purpose identified below.
+
+### Permitted Purpose
+
+A Permitted Purpose is any purpose other than a Competing Use. A Competing Use
+means making the Software available to others in a commercial product or service
+that:
+
+1. substitutes for the Software;
+
+2. substitutes for any other product or service we offer using the Software that
+   exists as of the date we make the Software available; or
+
+3. offers the same or substantially similar functionality as the Software.
+
+Permitted Purposes specifically include using the Software:
+
+1. for your internal use and access;
+
+2. for non-commercial education;
+
+3. for non-commercial research; and
+
+4. in connection with professional services that you provide to a licensee using
+   the Software in accordance with these Terms and Conditions.
+
+### Patents
+
+To the extent your use for a Permitted Purpose would necessarily infringe our
+patents, the license grant above includes a license under our patents. If you
+make a claim against any party that the Software infringes or contributes to the
+infringement of any patent, then your patent license to the Software ends
+immediately.
+
+### Redistribution
+
+The Terms and Conditions apply to all copies, modifications and derivatives of
+the Software.
+
+If you redistribute any copies, modifications or derivatives of the Software, you
+must include a copy of or a link to these Terms and Conditions and not remove any
+copyright notices provided in or with the Software.
+
+### Disclaimer
+
+THE SOFTWARE IS PROVIDED "AS IS" AND WITHOUT WARRANTIES OF ANY KIND, INCLUDING
+WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
+PURPOSE, NON-INFRINGEMENT, OR THAT THE SOFTWARE IS FREE OF DEFECTS. IN NO EVENT
+WILL WE HAVE ANY LIABILITY TO YOU ARISING OUT OF OR RELATED TO THE SOFTWARE,
+INCLUDING INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF WE HAVE
+BEEN INFORMED OF THEIR POSSIBILITY IN ADVANCE.
+
+### Grant of Future License
+
+We hereby irrevocably grant you an additional license to use the Software under
+the Apache License, Version 2.0 that is effective on the second anniversary of
+the date we make the Software available. On or after that date, you may use the
+Software under the Apache License, Version 2.0, in which case the following will
+apply:
+
+Licensed under the Apache License, Version 2.0 (the "License"); you may not use
+this file except in compliance with the License.
+
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software distributed
+under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR
+CONDITIONS OF ANY KIND, either express or implied. See the License for the
+specific language governing permissions and limitations under the License.

package/README.md

@@ -0,0 +1,24 @@
+# @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
+`@ours.network/fleet` CLI performs the actual lifecycle operations.
+
+## Install
+
+```sh
+npm install --global @ours.network/fleet-codex
+ours-fleet-codex-install
+```
+
+The installer ensures `@ours.network/fleet`, `@ours.network/codex`, and the
+native `ours` and `ours-fleet` Codex plugins are installed. Start a new Codex
+session after installation so it discovers the skills.
+
+Then ask Codex to “spawn an ours agent”, “create a persistent Codex role”, or
+“keep an eye on my fleet agents”.
+
+Codex may ask for one-time authorization before individual ours MCP tools run.
+Mail wake is consent-first: a spawned role receives `--monitor` only when the
+user explicitly requests it. `ours-codex` supplies background wake; native
+`codex` remains the supported foreground-monitor fallback.

package/bin/ours-fleet-codex-install.mjs

@@ -0,0 +1,31 @@
+#!/usr/bin/env node
+import { spawnSync } from 'node:child_process';
+
+const run = (command, args, { optional = false } = {}) => {
+  const result = spawnSync(command, args, { stdio: 'inherit' });
+  if (result.error || result.status !== 0) {
+    if (optional) return false;
+    const detail = result.error?.message ?? `exit ${result.status}`;
+    throw new Error(`${command} ${args.join(' ')} failed (${detail})`);
+  }
+  return true;
+};
+
+try {
+  if (!run('codex', ['--version'], { optional: true }))
+    throw new Error('Codex CLI is not installed or not on PATH');
+
+  console.log('Installing ours-fleet CLI and the ours Codex runtime...');
+  run('npm', ['install', '--global', '@ours.network/fleet', '@ours.network/codex']);
+  run('ours-codex-install', []);
+
+  console.log('Installing the ours-fleet native Codex plugin...');
+  if (!run('codex', ['plugin', 'marketplace', 'add', 'adapt-toolkit/ours-codex-marketplace'], { optional: true }))
+    run('codex', ['plugin', 'marketplace', 'upgrade', 'ours-codex-marketplace']);
+  run('codex', ['plugin', 'add', 'ours-fleet@ours-codex-marketplace']);
+
+  console.log('ours-fleet Codex support installed. Start a new Codex session, then ask: "spawn an ours agent".');
+} catch (error) {
+  console.error(`ours-fleet-codex-install: ${error.message}`);
+  process.exitCode = 1;
+}

package/package.json

@@ -0,0 +1,24 @@
+{
+  "name": "@ours.network/fleet-codex",
+  "version": "0.1.0",
+  "description": "Native Codex plugin for spawning, configuring, and overseeing ours-fleet agents.",
+  "type": "module",
+  "license": "FSL-1.1-Apache-2.0",
+  "author": "Adapt Framework Solutions Ltd",
+  "homepage": "https://github.com/adapt-toolkit/ours-fleet/tree/main/integrations/codex/ours-fleet#readme",
+  "repository": {
+    "type": "git",
+    "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"],
+  "bin": {
+    "ours-fleet-codex-install": "bin/ours-fleet-codex-install.mjs"
+  },
+  "engines": { "node": ">=20" },
+  "publishConfig": { "access": "public" },
+  "scripts": {
+    "test": "node --test"
+  }
+}

package/skills/oversee-agents/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: oversee-agents
+description: Inspect, monitor, and unstick ours-fleet agents from Codex using their tmux consoles 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
+
+Use fleet state and console output as evidence:
+
+```sh
+ours-fleet ls
+ours-fleet peek <Name> [lines]
+ours-fleet status <Name>
+ours-fleet logs <Name>
+ours-fleet send <Name> "<text>"
+ours-fleet send <Name> --key <key>
+```
+
+## Establish scope
+
+Identify wards from the user's request, the current role briefing, or agents
+just spawned. Confirm the desired check interval when ongoing oversight is
+requested; default to five minutes only after the user agrees.
+
+This plugin does not add a timer or Claude Code's generic scheduled background
+monitor. Before promising recurring checks, identify an explicit timer/recurring
+monitor tool that is actually available in the current Codex session. The ours
+mail monitor is event-driven and does not provide five-minute timer wakeups. If
+no real timer tool is present, say that the interval cannot be armed: offer
+active foreground observation or manual checks instead. Never say “I created a
+recurring monitor” based only on this skill. For durable operation, recommend a
+supervised coordinator role and message-driven wake through `ours-codex`, while
+remaining clear that messages—not elapsed time—wake it.
+
+## On each check
+
+Peek once and classify the evidence:
+
+- **Active and progressing:** leave it alone.
+- **Codex MCP authorization prompt:** surface the requested tool and scope.
+  Session-only approval is safer for tests; persistent approval requires the
+  user's explicit authorization.
+- **Permission or trust dialog:** choose only an option already authorized by
+  the role's mission and permission policy.
+- **Question waiting for an absent user:** answer only from known mission
+  context; otherwise escalate.
+- **Idle with unfinished work:** ask for status and direct it to continue or
+  declare `BLOCKED`.
+- **Crash or shell prompt:** inspect logs, diagnose, then restart permanent
+  roles with `ours-fleet restart <Name>` when safe.
+- **Completed temporary role:** report the result and let its supervisor clean
+  up; stop checking it.
+
+Never approve spending, deletion, publication, credential access, scope
+expansion, `danger-full-access`, or persistent plugin trust on the user's
+behalf. Escalate with the relevant pane snapshot and a concrete recommendation.
+
+Append material interventions to the current coordinator's durable worklog when
+one exists. Report the ward, observed state, action taken, and next check.

package/skills/oversee-agents/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Oversee Fleet Agents"
+  short_description: "Monitor and unstick spawned fleet agents"
+  default_prompt: "Use $oversee-agents to watch and assist my fleet roles."

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

@@ -0,0 +1,100 @@
+---
+name: spawn-ours-agent
+description: Spawn and configure a new ours-fleet agent from Codex, either as a supervised persistent role or a temporary tmux agent. 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 that should have its own ours identity and console.
+---
+
+# Spawn an ours-fleet agent
+
+Use the `ours-fleet` CLI to create the role. Do not simulate a subagent inside
+the current conversation.
+
+## 1. Check the host
+
+Run:
+
+```sh
+ours-fleet doctor --harness codex
+```
+
+Stop at a failed required check. Explain that `ours-codex` is preferred for
+background mail wake and native `codex` is the supported fallback.
+
+## 2. Resolve the role design
+
+Ask only for choices not already supplied:
+
+- **Lifetime:** permanent (supervised, restartable, survives reboot) or
+  temporary (one tmux session, removed on exit).
+- **Name:** `[A-Za-z0-9_-]+`; confirm it is absent from `ours-fleet config` and
+  `ours-fleet ls`.
+- **Mission and working directory.**
+- **Bio:** public 1–3 sentence card describing scope and when peers should
+  engage this role.
+- **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.
+- **Mail monitoring:** explicitly ask whether to arm it. Pass `--monitor` only
+  after a clear yes. This consent persists in the role configuration.
+
+Offer Codex controls when relevant; otherwise use safe defaults:
+
+- model: launcher default or `--model <id>`
+- approval: `untrusted`, `on-request`, or `never`
+- sandbox: `read-only`, `workspace-write`, or `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>`
+
+Default to `--harness codex --launcher auto --sandbox workspace-write
+--permission-mode on-request`. Never select `danger-full-access` or `never`
+without explicit user direction.
+
+## 3. Materialize approved profile text
+
+Use `apply_patch` to write the approved bio and persona to uniquely named files
+under `/tmp`. Do not interpolate untrusted text into a shell heredoc.
+
+## 4. Spawn
+
+Build an argument array from the approved choices. Permanent example:
+
+```sh
+ours-fleet spawn Worker --harness codex --launcher auto \
+  --mission "Own the worker implementation" --cwd /absolute/project \
+  --bio-file /tmp/worker-bio.md --persona-file /tmp/worker-persona.md \
+  --sandbox workspace-write --permission-mode on-request \
+  --coordinator Coordinator
+```
+
+Add `--temp` for a temporary role and `--monitor` only after monitoring consent.
+Pass model, profile, search, config, and additional directories exactly as
+approved. Do not persist secrets in `--codex-config` or fleet YAML; use the
+role's `env` configuration for environment-based credentials.
+
+## 5. Verify the real session
+
+Run:
+
+```sh
+ours-fleet peek <Name> 60
+ours-fleet status <Name>
+```
+
+For a temporary role, status may not have a system service; the tmux console is
+authoritative. 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 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
+before offering the blocking foreground fallback.
+
+## 6. Hand off oversight
+
+Treat the spawned role as a ward. Use the `oversee-agents` skill for immediate
+checks and interventions. State clearly whether ongoing timed oversight is
+actually armed or still requires manual checks.

package/skills/spawn-ours-agent/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Spawn ours Agent"
+  short_description: "Create a persistent or temporary fleet agent"
+  default_prompt: "Use $spawn-ours-agent to create a new Codex fleet role."