> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/sessions/phase12-session02-release-closeout-and-rollout-readiness/known-limitations-and-followups.md). # Known Limitations And Followups **Session ID**: `phase12-session02-release-closeout-and-rollout-readiness` **Package**: Cross-cutting **Date**: 2026-05-31 **Status**: Complete *** ## Release Position FactionOS is ready to describe Codex CLI support as first-class local hook support through direct user-level hooks, subject to the gate results recorded in `release-readiness-evidence.md`. This release remains local-first. It does not ship a Codex plugin package, hosted Codex telemetry, remote execution, production-hosted validation, or broad trusted erasure. *** ## Closed Questions | Question | Decision | Rationale | | ------------------------------------------------------------------------ | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | Should default `factionos init` remain Claude-only for one release? | Yes. | `factionos init` remains Claude Code by default; Codex uses explicit `--cli codex` or `--cli all`. This avoids surprising Codex hook writes. | | Should settings store one default `cli` or an `installedClis` list? | Keep current default `cli` for this release. | Release closeout found no blocker requiring a settings shape change. | | Should project-local `.codex/hooks.json` be supported now? | No. | Direct user-level hooks are validated; project-local trusted `.codex` setup remains deferred and user/Codex-owned. | | How much Codex MCP detail should FactionOS surface now? | Keep compact tool names and counts only. | MCP argument bodies remain blocked; no allowlisted argument labels are added in this closeout. | | Should `PreCompact` and `PostCompact` become visible mission events now? | No change in this release. | Existing evidence supports current diagnostics/contract posture; no release blocker requires new visible events. | *** ## Known Limitations | Limitation | Release status | Follow-up trigger | | ------------------------------------------------------------------------ | -------------- | ------------------------------------------------------------------------------------------------------------- | | Live Codex `/hooks` trust review is manual and interactive. | Accepted. | Future automation must not use trust-bypass flags as normal validation. | | Codex plugin packaging is deferred. | Accepted. | Reopen only when a concrete distribution need exists. | | No plugin install/cache/trust/uninstall validation. | N/A. | Only applicable after a plugin package exists. | | No project-local trusted `.codex` setup. | Accepted. | Reopen after direct user-level hooks have shipped and project-local trust rules are scoped. | | No hosted telemetry. | Accepted. | Future analytics must stay disabled by default and consent-gated. | | No production-hosted validation from this session. | Accepted. | Requires safe credentials, explicit HTTPS targets, and live hosted smoke pass. | | No remote execution. | Accepted. | Requires separate threat model, authorization, audit, and tests. | | No public replay hosting. | Accepted. | Requires consent, redaction, storage, expiration, takedown, abuse, and no-index design. | | No broad trusted erasure. | Accepted. | Requires release-record proof for every claimed boundary. | | Visual promotion gate retains metadata-pending and non-release warnings. | Accepted. | Future media promotion sessions must close the metadata and non-release blockers before broader media claims. | *** ## Follow-Up Work | Priority | Follow-up | Owner surface | Notes | | -------- | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------- | ---------------------------------------------------------------------------- | | P1 | Run live hosted smoke from an authorized release environment before any deployed public demo, Worker, or app-shell release claim. | Release/deployment | Use safe public HTTPS targets and sanitized output only. | | P2 | Reconsider Codex plugin packaging only with a concrete team, marketplace, bundled-skill, MCP, app, or publishing requirement. | Future plugin session | Reuse direct hook maps and privacy rules; do not fork a second runtime path. | | P2 | Design project-local `.codex` support only after user-level hook release settles. | CLI/hooks | Must keep Codex trust review user-owned. | | P2 | Evaluate richer MCP labels only with an allowlist and privacy tests. | Protocol/server/web/hooks | Raw MCP argument bodies remain blocked. | | P3 | Decide whether `PreCompact` and `PostCompact` should become visible mission events. | Protocol/server/web | Current release leaves them outside the visible mission-event claim. | | P3 | Close visual metadata-pending warnings for conditionally promoted media. | Media pipeline | Not a Codex release blocker. | *** ## Release Note Exclusions Exclude these from public release notes unless a later source-backed record changes the status: * Codex plugin availability. * Plugin install, plugin cache refresh, plugin trust review, or plugin uninstall success. * Hook trust bypass, automatic hook approval, or automatic Codex permission decisions. * Project-local trusted `.codex` setup. * Codex auth, provider, telemetry, model, profile, API key, account, or trusted-project mutation. * Hosted telemetry, hosted identity, hosted storage, analytics capture, public replay hosting, push delivery, tunnels, remote access, or remote execution. * Production-hosted validation. * Broad trusted unified erasure. *** ## Validation Handoff The validate workflow should verify: * `release-readiness-evidence.md` contains pass/no-claim/unavailable statuses for all required gates. * `privacy-security-release-review.md` remains boundary-specific. * `docs-release-review.md` records the API-doc wording fix. * `codex-release-notes.md` includes final gate outcomes and exclusions. * `rollout-readiness-checklist.md` marks direct install, status, doctor, uninstall, rollback, docs, and release-note handoff complete. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/sessions/phase12-session02-release-closeout-and-rollout-readiness/known-limitations-and-followups.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.