oacp-cli 0.3.4__tar.gz → 0.3.5__tar.gz

{oacp_cli-0.3.4 → oacp_cli-0.3.5}/CHANGELOG.md

@@ -5,6 +5,68 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.3.5] - 2026-07-11
+
+### Added
+
+- Receiver autonomy supports sender-marked `oacp-guardrails` fences, negation
+  fallback, declaration-aware lexical advisories, and a pinned reason-code
+  taxonomy backed by executable conformance fixtures.
+- `external_side_effects: allow_pr_artifacts` permits declared PR, review, and
+  issue-comment artifacts only for receiver-allowlisted private repositories,
+  while retaining pre-approval for public/unlisted artifacts, direct main
+  pushes, merges, deploys, and publishes.
+- Autonomy audit output records the full declared task profile, an explicit
+  breach list, a semantic policy hash, and a shared outcome block including
+  completion time and materialized-risk telemetry.
+- Default-off standing continuation grants now resolve from an explicit prior
+  human approval in the same conversation thread; sender-declared grant data
+  alone cannot authorize follow-up scope.
+- `oacp autonomy-outcome` atomically records structured approval, modification,
+  decline, latency, and grant-decision telemetry in schema-v2 autonomy audits.
+  The subcommand is exposed by the installed CLI starting with this release.
+- Envelope compilation: `oacp envelope compile|show|clear`
+  turns an admitted message's `task_profile` plus receiver config into a
+  runtime envelope (`active_envelope.json`), enforced at the tool-call layer
+  by a static Claude PreToolUse hook (`oacp-envelope-hook`, registered once
+  by `oacp setup claude`). Compilation is fail-closed
+  (`envelope_compile_error`), envelope drift denies with the canonical
+  threshold-checkpoint opener, unclassifiable calls escalate to `ask`, and
+  the audit outcome block records `envelope_enforcement: hooks | none`.
+  Contract pinned by executable fixtures under `tests/conformance/envelope/`.
+- The security policy documents the Tier-1.5 trust ceiling for single-OS-user
+  hosts: `from` fields are unauthenticated traceability today, future optional
+  signing would add tamper-evidence and provenance but not same-host
+  anti-impersonation, and hard isolation requires separate OS users,
+  containers, or hosts.
+
+### Changed
+
+- The versioning guide documents the staged release pipeline end to end,
+  replacing the retired single-repo flow.
+- Documentation examples and conformance fixtures use neutral example
+  repository slugs.
+- The standard `auto_review` estimate cap is 45 minutes; estimates above 45
+  still pause and the five-file cap remains unchanged.
+- Pricing and commercial matches remain hard pauses but now use the separate
+  `hard_stop_content_sensitivity` category.
+- Follow-up declarations outside a standing grant's time, file, or side-effect
+  scope re-pause before work begins.
+
+### Fixed
+
+- `doctor --memory` now forwards bounded network timeouts to remote Git fetches
+  without breaking custom runners that implement the original command interface.
+- The MCP stdio coordinator now converts unexpected request exceptions into
+  structured `-32603` responses instead of crashing the server.
+- Undeclared runtime side effects now produce `declaration_error` at the
+  threshold checkpoint instead of silently completing outside the profile.
+- Message validation now accepts and type-checks the six documented
+  review-loop telemetry fields: `model`, `turns`, `input_tokens`,
+  `output_tokens`, `wall_time_s`, and `est_cost_usd`.
+- Receiver config and doctor validation share one repository-slug regex instead
+  of maintaining duplicate definitions.
+
 ## [0.3.4] - 2026-06-11
 
 ### Fixed
@@ -192,6 +254,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Checkout step in github-release workflow job (#19)
 - Pre-release audit fixes: SHA-pinned actions, dangling doc refs (#15, #16)
 
+[0.3.5]: https://github.com/kiloloop/oacp/compare/v0.3.4...v0.3.5
 [0.3.4]: https://github.com/kiloloop/oacp/compare/v0.3.3...v0.3.4
 [0.3.3]: https://github.com/kiloloop/oacp/compare/v0.3.2...v0.3.3
 [0.3.2]: https://github.com/kiloloop/oacp/compare/v0.3.1...v0.3.2

{oacp_cli-0.3.4 → oacp_cli-0.3.5}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: oacp-cli
-Version: 0.3.4
+Version: 0.3.5
 Summary: Open Agent Coordination Protocol CLI for file-based multi-agent workflows
 Project-URL: Homepage, https://github.com/kiloloop/oacp
 Project-URL: Repository, https://github.com/kiloloop/oacp
@@ -120,6 +120,8 @@ $OACP_HOME/org-memory/                org-wide
 
 </details>
 
+Want to see these files populated? Browse [`examples/demo-workspace/`](examples/demo-workspace/) — what a fictional team's project remembers after a month of agent sessions (debt with origins, threads opened and closed, decisions with rationale), plus the org-memory layer mid-curation.
+
 ## Quick Start
 
 ```bash
@@ -146,9 +148,9 @@ When running inside a configured agent runtime, `--from` can be omitted — OACP
 
 ## Coming from `claude -p`?
 
-`claude -p` runs an agent synchronously and headless — your script blocks while it works, and as of June 15 programmatic usage draws from a separate metered credit.
+`claude -p` runs an agent synchronously and headless — your script blocks while it works, and there's no session to glance at, attach to, or steer mid-run.
 
-OACP routes the same work to a **standing interactive Claude Code session** instead: `oacp send` queues the task, the session picks it up and runs it async, you're not blocked — and because it's a real interactive session, it stays on your subscription.
+OACP routes the same work to a **standing interactive Claude Code session** instead: `oacp send` queues the task, the session picks it up and runs it async, you're not blocked — and the session is right there to watch and steer. Once tasks are messages, review loops, handoffs, and multi-agent coordination come with the shape.
 
 **[From `claude -p` to an interactive Claude Code session →](docs/from-claude-p.md)** — paste-into-your-agent setup, the honest tradeoffs, and where it fits.
 

{oacp_cli-0.3.4 → oacp_cli-0.3.5}/README.md

@@ -94,6 +94,8 @@ $OACP_HOME/org-memory/                org-wide
 
 </details>
 
+Want to see these files populated? Browse [`examples/demo-workspace/`](examples/demo-workspace/) — what a fictional team's project remembers after a month of agent sessions (debt with origins, threads opened and closed, decisions with rationale), plus the org-memory layer mid-curation.
+
 ## Quick Start
 
 ```bash
@@ -120,9 +122,9 @@ When running inside a configured agent runtime, `--from` can be omitted — OACP
 
 ## Coming from `claude -p`?
 
-`claude -p` runs an agent synchronously and headless — your script blocks while it works, and as of June 15 programmatic usage draws from a separate metered credit.
+`claude -p` runs an agent synchronously and headless — your script blocks while it works, and there's no session to glance at, attach to, or steer mid-run.
 
-OACP routes the same work to a **standing interactive Claude Code session** instead: `oacp send` queues the task, the session picks it up and runs it async, you're not blocked — and because it's a real interactive session, it stays on your subscription.
+OACP routes the same work to a **standing interactive Claude Code session** instead: `oacp send` queues the task, the session picks it up and runs it async, you're not blocked — and the session is right there to watch and steer. Once tasks are messages, review loops, handoffs, and multi-agent coordination come with the shape.
 
 **[From `claude -p` to an interactive Claude Code session →](docs/from-claude-p.md)** — paste-into-your-agent setup, the honest tradeoffs, and where it fits.
 

{oacp_cli-0.3.4 → oacp_cli-0.3.5}/SECURITY.md

@@ -29,6 +29,21 @@ OACP is a file-based coordination protocol. Security considerations include:
 - **Script injection** — Report any case where user-controlled input in message fields can lead to command injection via OACP scripts.
 - **Path traversal** — Report any case where message fields or script arguments can read or write files outside the intended directories.
 
+### Trust ceiling on shared hosts (Tier 1.5)
+
+On a single-OS-user host, OACP cannot *cryptographically prevent* one agent
+from impersonating another, because key-read access and inbox-write access
+collapse to the same uid. Today, `from` fields are unauthenticated and provide
+traceability only — not identity assurance. Message signing (an optional
+extension under design, not yet implemented) would add tamper-evidence and
+third-party-verifiable identity provenance for honest agents; it would still
+not provide same-host anti-impersonation. Hard inter-agent isolation requires
+one OS user per agent (Tier-2), containers, or separate hosts with enforced
+access controls. Hardware-backed keys can strengthen future signing identity
+assurance, but they do not isolate a shared filesystem or process space. Treat
+any `from` field on a shared host as **provenance, not an anti-spoofing
+guarantee.**
+
 ## Acknowledgments
 
 We appreciate responsible disclosure and will credit reporters in release notes (unless you prefer to remain anonymous).

{oacp_cli-0.3.4 → oacp_cli-0.3.5}/SPEC.md

@@ -79,7 +79,10 @@ Messages are YAML files. Filename convention: `<timestamp>_<from>_<type>.yaml`
 | `subject` | string | Subject line |
 | `body` | string | Message content (multi-line markdown) |
 
-**Optional fields:** `expires_at`, `channel`, `autonomy_hint`, `related_packet`, `related_pr`, `conversation_id`, `parent_message_id`, `context_keys`
+**Optional fields:** `expires_at`, `channel`, `autonomy_hint`, `related_packet`,
+`related_pr`, `conversation_id`, `parent_message_id`, `context_keys`, plus the
+review-loop telemetry fields `model`, `turns`, `input_tokens`, `output_tokens`,
+`wall_time_s`, and `est_cost_usd`
 
 `autonomy_hint` is an advisory sender hint, such as `auto_proceed`. Receivers
 remain authoritative: local autonomy config, message content, safety defaults,
@@ -88,6 +91,8 @@ interactive human confirmation.
 
 Receiver autonomy is defined by `agents/<receiver>/config.yaml` and the
 scope-envelope contract in [`docs/protocol/autonomy.md`](docs/protocol/autonomy.md).
+Sender-marked `oacp-guardrails` body fences and the 45-minute standard
+`auto_review` cap are defined there as well.
 
 ### Message Types
 

{oacp_cli-0.3.4 → oacp_cli-0.3.5}/docs/from-claude-p.md

@@ -1,12 +1,12 @@
 # From `claude -p` to an interactive Claude Code session
 
-On June 15, programmatic Claude usage — `claude -p`, the Agent SDK, Claude Code GitHub Actions, third-party tools — moves onto a separate metered monthly credit. Interactive Claude Code and chat stay on your subscription, unchanged.
+`claude -p` is how most people first script a Claude agent. It works — but if you run agents in automation, it's worth asking a question the one-liner never forces: **why is the agent headless and synchronous in the first place?**
 
-It's a reasonable change: programmatic usage is heavier and burstier than a person typing. But if you run agents in automation, it's worth asking a different question than "how do I dodge the meter" — **why is the agent headless and synchronous in the first place?**
+(A pricing footnote, since earlier versions of this page led with it: Anthropic explored moving programmatic usage — `claude -p`, the Agent SDK, Claude Code GitHub Actions — onto a separate metered credit, but paused that change before it took effect; per the June 15 announcement no such credit exists, subscription limits are unchanged, and advance notice is promised before any future version.)
 
 This guide is built to be handed to your agent. Read the first half for the *why*; paste the setup block into your Claude Code session for the *how*.
 
-> **Setup is a one-time ~5 minutes. Every task after that is one `oacp send` — async, non-blocking, on your subscription.**
+> **Setup is a one-time ~5 minutes. Every task after that is one `oacp send` — async, non-blocking, observable.**
 
 ## The shape of `claude -p`
 
@@ -14,7 +14,7 @@ This guide is built to be handed to your agent. Read the first half for the *why
 
 - it **blocks** — your script waits for the agent to finish
 - it runs **headless** — no session to glance at, attach to, or steer mid-run
-- after June 15, it's **metered** — programmatic usage draws from the separate credit pool
+- it's **one-shot** — one prompt in, one result out; there's no queue behind it, and coordinating several calls is your script's problem
 
 That shape was always a compromise. You wanted to script an agent, and `claude -p` was the way to do it from a shell. Synchronous-and-headless came along for the ride.
 
@@ -24,10 +24,10 @@ Run the agent as a **standing interactive Claude Code session**, and *send* it w
 
 ```
 Before:  claude -p "do X"
-         blocks · headless · metered after Jun 15
+         blocks · headless · one-shot
 
 After:   oacp send  →  a standing interactive session picks it up
-         async · you're not blocked · on your subscription
+         async · you're not blocked · a session you can watch
 ```
 
 Concretely — the call that replaces `claude -p "do X"`:
@@ -39,23 +39,23 @@ oacp send my-project --from sender --to claude --type task_request \
 
 Same prompt, different delivery. The text you'd have handed to `claude -p` becomes the message `--body`; `oacp send` drops it in the interactive session's inbox, and the session picks it up and runs it. Sending the prompt as an OACP message is the whole trick — it routes the work into a session running in interactive mode instead of a headless `claude -p` call.
 
-The session is a real interactive Claude Code session — so it stays on your subscription. You're not spoofing interactive mode; you're using it, and feeding it a queue.
+The session is a real interactive Claude Code session — you're not spoofing interactive mode; you're using it, and feeding it a queue.
 
-This isn't only about the credit. Async is the right shape for most automation — a build, an overnight refactor, a research job — none of it needs your script to sit and wait. And once tasks are messages in an inbox, you get real multi-agent coordination — review loops, handoffs, several agents on one project — instead of a pile of blocking shell calls.
+Async is the right shape for most automation — a build, an overnight refactor, a research job — none of it needs your script to sit and wait. And once tasks are messages in an inbox, you get real multi-agent coordination — review loops, handoffs, several agents on one project — instead of a pile of blocking shell calls.
 
 ## Your options, honestly
 
-Two real choices if June 15 affects you.
+Two real choices.
 
-**1. Pay the metered credit (or API rates).** Simplest. Low programmatic volume — the included credit may cover you; past that it's API pricing. Already on the API — nothing changes. No new tooling; it just costs money at scale.
+**1. Keep `claude -p`.** Simplest. It's one line, it works, and nothing about your setup changes. If your automation is a single blocking call and you never need to see inside it, this is fine.
 
-**2. OACP — run interactive for real, feed it a queue.** Run a real interactive Claude Code session and send it work. It stays on your subscription because it genuinely *is* an interactive session. Not a one-liner — it's a workflow change. In exchange you get real agent coordination, not just a credit workaround.
+**2. OACP — run interactive for real, feed it a queue.** Run a real interactive Claude Code session and send it work. Not a one-liner — it's a workflow change. In exchange you get async dispatch, a session you can watch and steer, and real agent coordination.
 
-Option 1 is the no-effort path that costs money at volume. Option 2 is a one-time workflow change that doesn't. Pick on that.
+Option 1 is zero effort and stays synchronous, headless, one-shot. Option 2 is a one-time workflow change that removes all three. Pick on that.
 
 ## What OACP is
 
-OACP isn't a June-15 tool. It's a file-based protocol for coordinating AI agents — inbox/outbox messaging, structured review loops, shared memory — no server, no daemon, just files in a directory. It was built to run a multi-agent fleet; the `claude -p` transition is **one usage** of it. Full picture: the [README](../README.md) and [SPEC](../SPEC.md). The companion [oacp-skills](https://github.com/kiloloop/oacp-skills) repo packages the runtime guidance — skills that teach Claude, Codex, and other agents to operate the protocol.
+OACP isn't a `claude -p` replacement tool. It's a file-based protocol for coordinating AI agents — inbox/outbox messaging, structured review loops, shared memory — no server, no daemon, just files in a directory. It was built to run a multi-agent fleet; the `claude -p` swap is **one usage** of it. Full picture: the [README](../README.md) and [SPEC](../SPEC.md). The companion [oacp-skills](https://github.com/kiloloop/oacp-skills) repo packages the runtime guidance — skills that teach Claude, Codex, and other agents to operate the protocol.
 
 ## Set it up — paste this into your agent
 
@@ -142,7 +142,7 @@ oacp-do() {
 
 **Request-response callers** — CI doing `RESULT=$(claude -p ...)` and using the output inline. Works too, but not a one-liner: the caller also arms `oacp watch --agent sender` to catch the reply. Worth it for a real pipeline — just know it's more than a swap.
 
-**If you just want zero workflow change** and don't care about coordination — keep `claude -p` and pay the meter (option 1). OACP earns its setup cost when you have more than one agent, recurring work, or you want to see and steer what the agent is doing. If that's not you, we'd rather say so.
+**If you just want zero workflow change** and don't care about coordination — keep `claude -p` (option 1). OACP earns its setup cost when you have more than one agent, recurring work, or you want to see and steer what the agent is doing. If that's not you, we'd rather say so.
 
 ## Try it
 

{oacp_cli-0.3.4 → oacp_cli-0.3.5}/docs/guides/doctor.md

@@ -13,7 +13,7 @@ No project, no config, no commit required — just install and run.
 
 ## What doctor checks
 
-Doctor organizes its output into five categories. When run without `--project`, only the first category (Environment) runs. With `--project <name>`, all five categories are evaluated.
+Doctor organizes its output into six categories. When run without `--project`, only the first category (Environment) runs. With `--project <name>`, all six categories are evaluated.
 
 ### 1. Environment
 
@@ -50,7 +50,19 @@ Validates YAML files against protocol expectations.
 - **packets/** — parses all `.yaml`/`.yml` files and reports syntax errors
 - **status.yaml** — checks required fields (`runtime`, `status`, `capabilities`, `updated_at`), validates enum values, and verifies timestamp format
 
-### 5. Agent Status
+### 5. Autonomy
+
+Validates each agent's receiver-autonomy setup (see `docs/protocol/autonomy.md`).
+
+- **config.yaml** — validates `autonomy.default_mode`, `auto_review_thresholds`
+  (numeric + policy keys, including `external_side_effects: pause |
+  allow_pr_artifacts | allow`), `allow_without_task_profile` entries, and
+  receiver-controlled `private_repo_allowlist` entries, and
+  `continuation_grants`; an absent config is fine (defaults to `always_pause`)
+- **audit directory** — warns if `agents/<agent>/audit/autonomy_decisions/` is missing
+- **orphaned policy refs** — warns when an audit event's `policy_path` points at a config file that no longer exists
+
+### 6. Agent Status
 
 Checks each agent's `status.yaml` for presence and freshness.
 
@@ -104,6 +116,14 @@ $ oacp doctor --project my-project
     [+] claude/status.yaml — valid
     [+] codex/status.yaml — valid
 
+[!] Autonomy
+    [+] claude/audit/autonomy_decisions — present
+    [+] claude/config.yaml — valid
+    [+] claude/autonomy audit — no orphaned policy refs
+    [!] codex/audit/autonomy_decisions — missing
+        mkdir -p $OACP_HOME/projects/my-project/agents/codex/audit/autonomy_decisions
+    [+] codex/config.yaml — absent; defaults to always_pause
+
 [!] Agent Status
     [+] claude/status.yaml — present
     [!] codex/status.yaml — stale (updated 26h ago)
@@ -179,6 +199,8 @@ oacp doctor                          # environment checks only
 oacp doctor --project <name>         # full workspace + agent checks
 oacp doctor --json                   # machine-readable JSON output
 oacp doctor --project <name> --json  # full checks in JSON format
+oacp doctor --project <name> --fix   # auto-fix safe issues (missing inbox dirs, missing/stale status.yaml)
+oacp doctor --memory                 # advisory checks for OACP_HOME memory git sync
 oacp doctor -o report.txt            # save report to file
 ```
 

{oacp_cli-0.3.4 → oacp_cli-0.3.5}/docs/guides/prompt_caching.md

@@ -94,7 +94,6 @@ Codex CLI sends the full prompt to the Codex API on each invocation. There is no
 
 4. **Lean on diff-only context**
    - For PR fix loops, pass the diff + findings rather than full file contents
-   - `run_agent_task.sh` already scopes context to changed files
 
 ## Gemini
 

{oacp_cli-0.3.4 → oacp_cli-0.3.5}/docs/guides/runtime_capability_matrix.md

@@ -1,12 +1,12 @@
 # Cross-Runtime Parity Matrix
 
-**Date**: 2026-06-09
+**Date**: 2026-06-26
 
 This is a capability comparison across the currently profiled agent runtimes (Claude Code, Codex, Gemini), compiled from each runtime's self-report and current runtime changelogs. Cursor support is scaffold-only until Cursor-owned onboarding lands, so Cursor is intentionally excluded from this comparison table; see `docs/protocol/runtime_capabilities.md` for its conservative scaffold defaults.
 
 Claude was last checked against Claude Code `v2.1.170` with Claude Fable 5 (`claude-fable-5`, serving model verified in-session on the 1M-context variant). Fable 5 (released 2026-06-09, first Mythos-class model) is included at no extra cost on Pro/Max/Team/Enterprise plans Jun 9–22, 2026, with usage credits required after; Opus 4.8 remains available and serves as Fable 5's safeguard-fallback model.
 
-Codex was last checked against app update `26.602`, CLI `0.137.0`, OpenAI's GPT-5.5 launch note from 2026-04-23, and the June 2026 Codex/API entries for Sites and Amazon Bedrock.
+Codex was last checked against app update `26.616`, CLI `0.142.3`, the local desktop app `26.623.31921`, OpenAI's GPT-5.5 launch note from 2026-04-23, and the June 2026 Codex/API entries for Sites, Amazon Bedrock, Remote, and Record & Replay.
 
 ---
 
@@ -17,16 +17,16 @@ Codex was last checked against app update `26.602`, CLI `0.137.0`, OpenAI's GPT-
 | Spawn background tasks | Yes — Task tool + Bash `run_in_background`                                 | Yes — shell background processes                                                               | Yes — `run_command` async mode                                        |
 | Spawn subagents        | Yes — typed agents (Explore, Plan, general-purpose, code-reviewer, etc.)   | Yes — native multi-agent lifecycle with runtime metadata and follow-up defaults                | Partial — `browser_subagent` only                                     |
 | Parallel agent teams   | Yes — TeamCreate, task lists, SendMessage, broadcast                       | Partial — parallel spawned agents are supported, but there is no team/task-list primitive      | No — parallel tool calls but no independent agent instances           |
-| MCP tools              | Yes — extensible via MCP servers                                           | Yes — MCP/plugin support with `/mcp verbose`, per-server environment targeting, read-only MCP parallelism, and scriptable plugin inventory | Yes — MCP server support                                              |
+| MCP tools              | Yes — extensible via MCP servers                                           | Yes — MCP/plugin support with `/mcp verbose`, per-server environment targeting, read-only MCP parallelism, scriptable plugin inventory, and default tool-search exposure where supported | Yes — MCP server support                                              |
 | Web search             | Yes — native WebSearch tool                                                | Yes — web search/fetch tools; hosted web tools are expanding in code-mode flows                | Yes — native `search_web` tool                                        |
 | Browser interaction    | Partial — WebFetch (read-only, HTML→markdown)                              | Partial — in-app browser and Chrome extension can inspect local/public and approved browser contexts, with faster asset extraction and read-only JS structured-data extraction; not full browser automation | Yes — full browser control (click, type, navigate, screenshot, video) |
 | File system access     | Sandboxed — configurable read/write allowlists                             | Policy-dependent per session; named permission profiles can include deny-read rules and managed requirements | Full — unrestricted                                                   |
 | Git operations         | Yes — via Bash (may need sandbox configuration)                            | Yes — native                                                                                   | Yes — via shell                                                       |
 | GitHub CLI (gh)        | Yes — via Bash (may need sandbox configuration)                            | Yes — authenticated                                                                            | Yes — native                                                          |
 | Session memory         | Strong — auto-loaded MEMORY.md + optional MCP memory                       | Partial — app memories where available plus OACP file memory; app memories are not protocol SSOT | Partial — Knowledge Items (not directly writable), conversation logs  |
-| Interactive mode       | Yes — CLI chat with permissions, plan mode                                 | Yes — desktop app and CLI/TUI, including Plan Mode, Goal mode, side conversations, and archive/unarchive flows | Yes — chat with task UI, artifacts                                    |
+| Interactive mode       | Yes — CLI chat with permissions, plan mode                                 | Yes — desktop app and CLI/TUI, including Plan Mode, Goal mode, side conversations, archive/unarchive/delete flows, and token-budget-aware long-running work | Yes — chat with task UI, artifacts                                    |
 | Context window         | ~1M with Fable 5 or Opus 4.8 (auto-compaction extends indefinitely)        | Model-dependent; GPT-5.5 in Codex is documented at 400K, with no auto-compaction guarantee      | ~1M tokens                                                            |
-| Cost model             | Token-based, visible in statusline; Fable 5 API rate is $10/$50 per MTok (2× Opus 4.8's $5/$25) | Not surfaced per session; GPT-5.5 Fast mode trades 2.5x cost for 1.5x token generation speed   | Token-based                                                           |
+| Cost model             | Token-based, visible in statusline; Fable 5 API rate is $10/$50 per MTok (2× Opus 4.8's $5/$25) | Not surfaced per session; GPT-5.5 Fast mode trades 2.5x cost for 1.5x token generation speed, and newer CLI builds add explicit token budgets for bounded work | Token-based                                                           |
 | Sandbox restrictions   | Yes — configurable allowlists                                              | Session-dependent; supports deny-read policies, isolated `codex exec`, named permission profiles, managed requirements, and explicit approval policies | None — full system access                                             |
 
 ---
@@ -57,6 +57,8 @@ Codex was last checked against app update `26.602`, CLI `0.137.0`, OpenAI's GPT-
 | Hosted site deployment           | Codex         | Sites preview can create, deploy, inspect, and manage hosted websites or internal tools through the Codex app |
 | Plugin marketplace inventory     | Codex         | Plugin directory plus `codex plugin list --json` for installed plugin inventory and marketplace-aware diagnostics |
 | Goal mode                        | Codex         | Stable long-running objective mode with dedicated state; candidate for OACP wait/review-loop experiments |
+| Record & Replay                  | Codex         | Mac desktop workflows can be recorded and converted into reusable skills; candidate for private skill capture after privacy review |
+| Current-time reminders           | Codex         | CLI can remind agents of current time/date context; useful for protocol work with relative dates and scheduled waits |
 
 ---
 
@@ -97,6 +99,7 @@ Scope: skills shipped in [`kiloloop/oacp-skills`](https://github.com/kiloloop/oa
 | Context limits                | Auto-compaction mitigates     | Model-dependent; GPT-5.5 in Codex is 400K, but there is no documented auto-compaction behavior | Large but finite       |
 | No terminal stdin             | Yes                           | —                                                              | —                      |
 | Cost not surfaced             | —                             | Yes                                                            | —                      |
+| Permanent session delete      | —                             | `codex delete` is available; use archive/unarchive for routine cleanup and reserve delete for explicit destructive cleanup | —                      |
 | Serving model can change mid-session | Yes (Fable 5 only — cyber/bio-chem/distillation classifiers fall back to Opus 4.8; default and non-configurable in Claude interfaces incl. Claude Code, with a session event emitted; <5% of sessions — system card §1.5) | — | — |
 
 ---
@@ -135,16 +138,17 @@ These are the highest-impact gaps where one runtime's limitation blocks effectiv
 | Workflow file format         | SKILL.md with YAML frontmatter   | SKILL.md with YAML frontmatter             | Markdown with YAML frontmatter                |
 | Policy visibility at runtime | Partial (sandbox config visible) | Yes (session policy, approval policy, sandbox, and named permission profiles) | Yes (`SafeToAutoRun` flags)                   |
 | Long-running shell sessions  | Bash tool (no stdin)             | Yes (PTY + stdin; multiple terminals in app) | Yes (`send_command_input`)                    |
-| App-server / SDK             | No                               | Yes (JSON-RPC app-server, Python SDK, archive/thread APIs, schema generation) | No                                            |
+| App-server / SDK             | No                               | Yes (JSON-RPC app-server, Python SDK, archive/thread APIs, schema generation, remote execution improvements, and multi-agent continuation surfaces) | No                                            |
 | Hosted site deployment       | No                               | Yes (Sites preview, app-only/cloud-hosted with separate secret management) | No                                            |
+| Desktop workflow capture     | No                               | Yes (Record & Replay on Mac; privacy-sensitive and best treated as private-skill capture until reviewed) | No                                            |
 
 ---
 
 ## 8. Source Notes
 
 - GPT-5.5 Codex availability, 400K context, Fast mode, token-efficiency, and API timing come from OpenAI's 2026-04-23 release note: <https://openai.com/index/introducing-gpt-5-5/>.
-- Codex app/CLI capability changes through app `26.602` and CLI `0.137.0` come from OpenAI's Codex changelog: <https://developers.openai.com/codex/changelog>.
-- Sites, Amazon Bedrock, app-server, plugin, and permissions details come from the official Codex docs under <https://developers.openai.com/codex/>.
+- Codex app/CLI capability changes through app `26.616`, CLI `0.142.3`, and the local desktop app `26.623.31921` come from OpenAI's Codex changelog and local Codex runtime checks: <https://developers.openai.com/codex/changelog>.
+- Sites, Amazon Bedrock, Remote, Record & Replay, app-server, plugin, and permissions details come from the official Codex docs under <https://developers.openai.com/codex/>.
 - Claude Fable 5 release date, pricing, and plan-inclusion window come from Anthropic's 2026-06-09 announcement: <https://www.anthropic.com/news/claude-fable-5-mythos-5>. Safeguard-fallback behavior comes from the Fable 5 / Mythos 5 system card §1.5 ("Novel safeguards"): client apps and Claude interfaces auto-fall back to Opus 4.8 (default and non-configurable in interfaces, session event emitted), while the Messages API blocks by default with a structured refusal category and offers opt-in server-side fallback. The serving model in the header was verified in-session by the Claude runtime.
 
 ---

{oacp_cli-0.3.4 → oacp_cli-0.3.5}/docs/guides/setup.md

@@ -80,7 +80,6 @@ For Claude Code projects, copy templates into the repo's `.claude/` directory:
 # From the oacp repo root:
 cp templates/claude/agents/role_agent.template.md /path/to/repo/.claude/agents/<role>.md
 cp templates/claude/rules/guardrail.template.md /path/to/repo/.claude/rules/guardrails.md
-cp templates/claude/skills/session_lifecycle.template.md /path/to/repo/.claude/skills/lifecycle/SKILL.md
 ```
 
 ## 5) Initialize packet files (source checkout only)

{oacp_cli-0.3.4 → oacp_cli-0.3.5}/docs/guides/unified_skill_spec.md

@@ -179,7 +179,7 @@ Once both runtimes can resolve a shared skill path (e.g., `shared/skills/<name>/
 
 ## Example: check-inbox (unified)
 
-See the current Claude and Codex implementations:
+See the current Claude and Codex implementations in the [oacp-skills](https://github.com/kiloloop/oacp-skills) repo:
 - `claude/skills/check-inbox/SKILL.md`
 - `codex/skills/check-inbox/SKILL.md`
 

oacp_cli-0.3.5/docs/guides/versioning.md

@@ -0,0 +1,65 @@
+# Versioning Guide
+
+The `oacp-cli` package follows semantic versioning:
+
+- `v0.x.y` while the CLI surface and protocol are still stabilizing.
+- `v1.0.0` once format fields and loop controls are stable.
+
+## Change Types
+
+- Patch (`x.y.Z`): wording fixes, non-breaking docs improvements.
+- Minor (`x.Y.0`): new optional fields/templates/scripts.
+- Major (`X.0.0`): breaking template/protocol changes.
+
+## Where the Version Lives
+
+`pyproject.toml` is the single source of truth. `oacp/__init__.py` resolves
+`__version__` at runtime via `importlib.metadata`, so `oacp --version` always
+reports the installed package version — the version number itself is edited in
+exactly one file (the release-bump PR also adds the matching `CHANGELOG.md`
+section, see below).
+
+## Release Pipeline
+
+Releases flow through a staged promotion: development repo → private staging
+repo (soak) → public repo (`kiloloop/oacp`) → PyPI. Every repository content
+change lands via a reviewed pull request (branch protection enforces squash
+merges and rejects direct pushes); the one non-PR step is the release tag
+itself, which triggers the publish workflow.
+
+1. **Pre-export audit** — run `make preflight ARGS="--full"` (conflict-marker
+   scan, Makefile checks, YAML validation, ruff, shellcheck, full test suite),
+   then scan for leaks: hardcoded user paths, private repository references,
+   secret patterns, and SPDX headers on all tracked Python files. All checks
+   must pass before anything is exported.
+2. **Version bump PR** — update the `version` in `pyproject.toml` and add a
+   `CHANGELOG.md` section in [Keep a Changelog](https://keepachangelog.com/en/1.1.0/)
+   format. Gather the changes with `git log --oneline <last-tag>..HEAD`.
+3. **Export to staging** — open a staging PR mirroring the development branch.
+   The export copies the tracked tree only (`git archive`), so gitignored
+   local files never leave the development machine; rerun the leak audit on
+   the staged tree before merging. Non-urgent releases soak here before
+   promotion; urgent fixes may skip the soak.
+4. **Promote to public** — open a promotion PR into `kiloloop/oacp` under the
+   release automation identity; a human reviews and merges it. The squash
+   commit message becomes permanent public history — keep it free of internal
+   references (the PR description alone is not what gets published).
+5. **Tag and publish** — push an annotated `vX.Y.Z` tag to the public repo
+   (a direct tag push, not a PR). The tag-triggered release workflow reruns
+   the checks, builds the sdist/wheel, publishes `oacp-cli` to PyPI via
+   [Trusted Publishing](https://docs.pypi.org/trusted-publishers/) (OIDC — no
+   long-lived API tokens), and creates the GitHub Release with notes from the
+   CHANGELOG section.
+6. **Verify** — check the version-pinned endpoint
+   `https://pypi.org/pypi/oacp-cli/<version>/json` first; the unversioned
+   "latest" endpoint and the pip simple index can lag a few minutes behind it.
+   Then install and confirm `oacp --version` prints the new version. On a
+   machine with an existing uv-managed install, replace it explicitly —
+   `uv cache prune`, `uv tool uninstall oacp-cli`, then
+   `uv tool install oacp-cli==<version> --no-cache`; the short
+   `uv tool install` form is only reliable in a clean tool environment.
+
+## Doc-Only Changes
+
+Documentation-only updates promote through the same two-PR staging path
+(staging PR plus public PR) with no version bump, no tag, and no PyPI publish.