oh-my-codex 0.16.1 → 0.16.2

package/plugins/oh-my-codex/skills/ultragoal/SKILL.md

@@ -9,7 +9,7 @@ Use when the user asks for `ultragoal`, `create-goals`, `complete-goals`, durabl
 
 ## Purpose
 
-`ultragoal` turns a brief into repo-native artifacts and then drives one goal at a time through Codex goal tools:
+`ultragoal` turns a brief into repo-native artifacts and then drives a Codex goal safely through goal tools. New plans default to an aggregate Codex goal for the whole ultragoal run while OMX tracks G001/G002 story progress in the ledger.
 
 - `.omx/ultragoal/brief.md`
 - `.omx/ultragoal/goals.json`
@@ -21,6 +21,7 @@ Use when the user asks for `ultragoal`, `create-goals`, `complete-goals`, durabl
    - `omx ultragoal create-goals --brief "<brief>"`
    - `omx ultragoal create-goals --brief-file <path>`
    - `cat <brief> | omx ultragoal create-goals --from-stdin`
+   - `omx ultragoal create-goals --codex-goal-mode per-story --brief "<brief>"` only when one fresh Codex thread per story is explicitly preferred
 2. Inspect `.omx/ultragoal/goals.json` and refine if needed.
 
 ## Complete goals
@@ -30,20 +31,23 @@ Loop until `omx ultragoal status` reports all goals complete:
 1. Run `omx ultragoal complete-goals`.
 2. Read the printed handoff.
 3. Call `get_goal`.
-4. If no active Codex goal exists, call `create_goal` with the printed payload.
-5. Complete that single goal only.
-6. Run a completion audit against the objective and real artifacts/tests.
-7. When complete, call `update_goal({status: "complete"})`, then call `get_goal` again for a fresh completion snapshot.
+4. If no active Codex goal exists, call `create_goal` with the printed payload. In aggregate mode, if the same aggregate Codex objective is already active, continue the current OMX story without creating a new Codex goal.
+5. Complete the current OMX story only.
+6. Run a completion audit against the story objective and real artifacts/tests.
+7. In aggregate mode, do **not** call `update_goal` for intermediate stories; checkpoint with a fresh `get_goal` snapshot whose aggregate objective is still `active`. On the final story only, call `update_goal({status: "complete"})`, then call `get_goal` again for a fresh `complete` snapshot.
 8. Checkpoint the durable ledger with that snapshot:
    `omx ultragoal checkpoint --goal-id <id> --status complete --evidence "<evidence>" --codex-goal-json <get_goal-json-or-path>`
 9. If blocked or failed, checkpoint failure:
    `omx ultragoal checkpoint --goal-id <id> --status failed --evidence "<blocker/evidence>"`
-10. Resume failed goals with `omx ultragoal complete-goals --retry-failed`.
+10. For legacy per-story completed-goal blockers, preserve the non-terminal blocker with:
+   `omx ultragoal checkpoint --goal-id <id> --status blocked --evidence "<completed legacy Codex goal blocks create_goal in this thread>" --codex-goal-json <get_goal-json-or-path>`
+11. Resume failed goals with `omx ultragoal complete-goals --retry-failed`.
 
 ## Constraints
 
 - The shell command cannot directly invoke Codex interactive `/goal`; it emits a model-facing handoff for the active Codex agent.
 - Never call `create_goal` when `get_goal` reports a different active goal.
-- Never call `update_goal` unless the current goal is actually complete.
+- Never call `update_goal` unless the aggregate run or legacy per-story goal is actually complete.
+- In aggregate mode, intermediate story checkpoints require a matching `active` Codex snapshot; final story completion requires a matching `complete` snapshot after `update_goal`.
 - Completion checkpoints require read-only Codex snapshot reconciliation: pass fresh `get_goal` JSON/path with `--codex-goal-json`; shell commands and hooks must not mutate Codex goal state.
 - Treat `ledger.jsonl` as the durable audit trail; checkpoint after every success or failure.

package/plugins/oh-my-codex/skills/wiki/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wiki
-description: Persistent markdown project wiki stored under .omx/wiki with keyword search and lifecycle capture
+description: Persistent markdown project wiki stored under repository omx_wiki with keyword search and lifecycle capture
 triggers: ["wiki add", "wiki lint", "wiki query", "wiki read", "wiki delete"]
 ---
 
@@ -42,9 +42,9 @@ wiki_refresh()
 `architecture`, `decision`, `pattern`, `debugging`, `environment`, `session-log`, `reference`, `convention`
 
 ## Storage
-- Pages: `.omx/wiki/*.md`
-- Index: `.omx/wiki/index.md`
-- Log: `.omx/wiki/log.md`
+- Pages: `omx_wiki/*.md`
+- Index: `omx_wiki/index.md`
+- Log: `omx_wiki/log.md`
 
 ## Cross-References
 Use `[[page-name]]` wiki-link syntax to create cross-references between pages.
@@ -54,4 +54,4 @@ At session end, discoveries can be captured as `session-log-*` pages. Configure
 
 ## Hard Constraints
 - No vector embeddings — query uses keyword + tag matching only
-- Wiki files remain local project state under `.omx/wiki/`
+- Wiki files are repository project knowledge under `omx_wiki/`; legacy `.omx/wiki/` is read-only compatibility input when no canonical wiki exists

package/prompts/planner.md

@@ -59,7 +59,7 @@ Leave execution with a right-sized, evidence-grounded plan: scope, steps, accept
 - Codebase facts come from inspection.
 - Plan is saved to `.omx/plans/{name}.md`.
 - User confirmation is obtained before handoff.
-- Consensus mode includes complete RALPLAN-DR, ADR, an explicit available-agent-types roster, staffing guidance for team and ralph follow-up paths, product-facing goal-mode follow-up suggestions (`$ultragoal` generally, `$autoresearch-goal` for research projects, `$performance-goal` for optimization/performance projects), suggested reasoning levels by lane, launch hints, and a team verification path when needed.
+- Consensus mode includes complete RALPLAN-DR, ADR, an explicit available-agent-types roster, staffing guidance for team and ralph follow-up paths, product-facing goal-mode follow-up suggestions (`$ultragoal` generally and by default, `$autoresearch-goal` for research projects, `$performance-goal` for optimization/performance projects), suggested reasoning levels by lane, launch hints, and a team verification path when needed.
 </success_criteria>
 
 <tools>

package/skills/deep-interview/SKILL.md

@@ -365,7 +365,7 @@ Present execution options after artifact generation using explicit handoff contr
 
 Include these product-facing suggestions when they fit the clarified spec, without removing the existing `$ralplan`, `$autopilot`, `$ralph`, and `$team` handoff options:
 
-- **`$ultragoal`** — use for general goal-oriented follow-up when the spec should be converted into durable Codex goals with sequential completion tracking.
+- **`$ultragoal`** — default goal-mode follow-up for implementation or general goal-oriented follow-up specs that should be converted into durable Codex/OMX goals with sequential completion tracking.
 - **`$autoresearch-goal`** — use when the clarified context is a research project: a research question, reference/literature gathering, evaluator-backed analysis, or professor/critic-style deliverable.
 - **`$performance-goal`** — use when the clarified context is an optimization or performance project with measurable speed, latency, throughput, memory, benchmark, or evaluator criteria.
 
@@ -378,7 +378,7 @@ Preserve `$ralph` for persistent single-owner execution/verification and `$team`
 - **Skipped / Already-Satisfied Stages:** Requirements discovery, ambiguity clarification, and early intent-boundary elicitation
 - **Expected Output:** Canonical planning artifacts under `.omx/plans/`, especially `prd-*.md` and `test-spec-*.md`
 - **Best When:** Requirements are clear enough to stop interviewing, but architectural validation / consensus planning is still desirable
-- **Next Recommended Step:** Use the approved planning artifacts with `$autopilot`, `$ralph`, `$team`, or a goal-mode follow-up (`$ultragoal`, `$autoresearch-goal`, `$performance-goal`) depending on whether the next need is direct execution, coordination, durable goals, research validation, or measurable optimization
+- **Next Recommended Step:** Use the approved planning artifacts with `$autopilot`, `$ralph`, `$team`, or `$ultragoal` as the default goal-mode follow-up; choose `$autoresearch-goal` for research validation or `$performance-goal` for measurable optimization
 
 ### 2. **`$autopilot`**
 - **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`

package/skills/omx-setup/SKILL.md

@@ -74,7 +74,7 @@ Use this map when reconciling setup behavior or debugging a confusing install:
 | Surface | Owner | Notes |
 | --- | --- | --- |
 | `./.omx/setup-scope.json` | `omx setup` | Persists setup scope and user-scope skill delivery mode. TTY reruns summarize it and offer keep/review/reset. |
-| `~/.codex/config.toml` / `./.codex/config.toml` | `omx setup` generated blocks + user edits | Setup refreshes OMX-managed blocks while preserving supported manual content; setup-owned runtime feature flags include `multi_agent`, `child_agents_md`, `codex_hooks`, and `goals`. |
+| `~/.codex/config.toml` / `./.codex/config.toml` | `omx setup` generated blocks + user edits | Setup refreshes OMX-managed blocks while preserving supported manual content; setup-owned runtime feature flags include `multi_agent`, `child_agents_md`, `hooks`, and `goals`. |
 | `~/.codex/hooks.json` / `./.codex/hooks.json` | `omx setup` shared ownership | Setup owns OMX native hook wrappers and preserves user-owned hooks. |
 | prompts, skills, native agents | `omx setup` or Codex plugin delivery | Legacy mode installs local files; plugin mode relies on plugin discovery for bundled skills and archives/removes legacy OMX-managed prompt/native-agent copies. |
 | `AGENTS.md` | `omx setup` with overwrite safety | Generated defaults or managed refreshes are guarded by force/session checks. |

package/skills/plan/SKILL.md

@@ -95,12 +95,12 @@ Jumping into code without understanding requirements leads to rework, scope cree
    c. Update the plan file in `.omx/plans/` with the accepted improvements (add missing details, refine steps, strengthen acceptance criteria, ADR updates, etc.)
    d. Note which improvements were applied in a brief changelog section at the end of the plan
    e. Before any execution handoff, derive an explicit **available-agent-types roster** from the known prompt catalog and add concrete **follow-up staffing guidance** for both `$ralph` and `$team` (recommended roles, counts, suggested reasoning levels by lane, and why each lane exists)
-   f. Add a product-facing **Goal-Mode Follow-up Suggestions** section: suggest `$ultragoal` for general goal-oriented follow-up, `$autoresearch-goal` when the context is a research project, and `$performance-goal` when the context is an optimization or performance project. Keep these suggestions alongside the Ralph/team paths rather than replacing them when implementation delivery is still the main need.
+   f. Add a product-facing **Goal-Mode Follow-up Suggestions** section: recommend `$ultragoal` by default for general goal-oriented follow-up, `$autoresearch-goal` when the context is a research project, and `$performance-goal` when the context is an optimization or performance project. Keep these suggestions alongside the Ralph/team paths rather than replacing them when implementation delivery is still the main need.
    g. For the `$team` path, add an explicit launch-hint block with concrete `omx team` / `$team` commands and a **team verification path** (what team proves before shutdown, what Ralph verifies after handoff)
 7. On Critic approval (with improvements applied): *(--interactive only)* If running with `--interactive`, use `AskUserQuestion` / the structured question UI to present the plan with these options:
    - **Approve and execute** — proceed to implementation via ralph+ultrawork
    - **Approve and implement via team** — proceed to implementation via coordinated parallel team agents
-   - **Start goal-mode follow-up** — proceed via `$ultragoal`, `$autoresearch-goal`, or `$performance-goal` when the approved plan fits durable goals, research validation, or measurable optimization
+   - **Start goal-mode follow-up** — proceed via `$ultragoal` by default, or `$autoresearch-goal` / `$performance-goal` when the approved plan specifically fits research validation or measurable optimization
    - **Request changes** — return to step 1 with user feedback
    - **Reject** — discard the plan entirely
    If NOT running with `--interactive`, output the final approved plan and stop. Do NOT auto-execute.
@@ -108,7 +108,7 @@ Jumping into code without understanding requirements leads to rework, scope cree
 9. On user approval (--interactive only):
    - **Approve and execute**: **MUST** invoke `$ralph` with the approved plan path from `.omx/plans/` as context **plus the explicit available-agent-types roster, suggested reasoning levels, concrete role allocation guidance, and direct launch hints for Ralph follow-up work**. Do NOT implement directly. Do NOT edit source code files in the planning agent. The ralph skill handles execution via ultrawork parallel agents.
    - **Approve and implement via team**: **MUST** invoke `$team` with the approved plan path from `.omx/plans/` as context **plus the explicit available-agent-types roster, suggested reasoning levels, concrete staffing / worker-role allocation guidance, explicit `omx team` / `$team` launch hints, and the team verification path**. Do NOT implement directly. The team skill coordinates parallel agents across the staged pipeline for faster execution on large tasks.
-   - **Start goal-mode follow-up**: **MUST** invoke the selected goal workflow with the approved plan path and appropriate success context: `$ultragoal` for general goal-oriented follow-up, `$autoresearch-goal` for research projects, or `$performance-goal` for optimization/performance projects with measurable evaluator criteria. Do NOT implement directly in the planning agent.
+   - **Start goal-mode follow-up**: **MUST** invoke the selected goal workflow with the approved plan path and appropriate success context: `$ultragoal` as the default goal-mode path, `$autoresearch-goal` for research projects, or `$performance-goal` for optimization/performance projects with measurable evaluator criteria. Do NOT implement directly in the planning agent.
 
 ### Review Mode (`--review`)
 
@@ -150,7 +150,7 @@ Plans are saved to `.omx/plans/`. Drafts go to `.omx/drafts/`.
 - In consensus mode, default to RALPLAN-DR short mode; enable deliberate mode on `--deliberate` or explicit high-risk signals (auth/security, migrations, destructive changes, production incidents, compliance/PII, public API breakage)
 - In consensus mode with `--interactive`: use `AskUserQuestion` / the structured question UI for the user feedback step (step 2) and the final approval step (step 7) -- never ask for approval in plain text when a structured surface is available. Without `--interactive`, auto-proceed through planning steps without pausing. Output the final plan without execution.
 - In consensus mode with `--interactive`, on user approval **MUST** invoke the selected follow-up lane from step 9 (`$ralph`, `$team`, `$ultragoal`, `$autoresearch-goal`, or `$performance-goal`) -- never implement directly in the planning agent
-- In consensus mode, execution follow-up handoff **MUST** include an explicit available-agent-types roster plus concrete staffing / role-allocation guidance grounded in that roster, suggested reasoning levels by lane, product-facing goal-mode follow-up suggestions (`$ultragoal` generally, `$autoresearch-goal` for research projects, `$performance-goal` for optimization/performance projects), explicit `omx team` / `$team` launch hints, and a team verification path
+- In consensus mode, execution follow-up handoff **MUST** include an explicit available-agent-types roster plus concrete staffing / role-allocation guidance grounded in that roster, suggested reasoning levels by lane, product-facing goal-mode follow-up suggestions (`$ultragoal` by default, `$autoresearch-goal` for research projects, `$performance-goal` for optimization/performance projects), explicit `omx team` / `$team` launch hints, and a team verification path
 </Tool_Usage>
 
 

package/skills/ralplan/SKILL.md

@@ -54,7 +54,7 @@ The consensus workflow:
    d. Return to Critic evaluation
    e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached
    f. If 5 iterations are reached without `APPROVE`, present the best version to the user
-6. On Critic approval *(--interactive only)*: If `--interactive` is set, use the structured question UI to present the plan with approval options (Approve and execute via ralph / Approve and implement via team / Start a goal-mode follow-up / Request changes / Reject). Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups), an explicit available-agent-types roster, concrete follow-up staffing guidance for both `ralph` and `team`, suggested reasoning levels by lane, explicit `omx team` / `$team` launch hints, a concrete **team verification** path, and a product-facing **Goal-Mode Follow-up Suggestions** section. Suggest `$ultragoal` for general goal-oriented follow-up, `$autoresearch-goal` when the context is a research project, and `$performance-goal` when the context is an optimization or performance project. Otherwise, output the final plan and stop.
+6. On Critic approval *(--interactive only)*: If `--interactive` is set, use the structured question UI to present the plan with approval options (Approve and execute via ralph / Approve and implement via team / Start a goal-mode follow-up / Request changes / Reject). Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups), an explicit available-agent-types roster, concrete follow-up staffing guidance for both `ralph` and `team`, suggested reasoning levels by lane, explicit `omx team` / `$team` launch hints, a concrete **team verification** path, and a product-facing **Goal-Mode Follow-up Suggestions** section. Recommend `$ultragoal` by default for goal-mode follow-up, use `$autoresearch-goal` instead when the context is a research project, and use `$performance-goal` instead when the context is an optimization or performance project. Otherwise, output the final plan and stop.
 7. *(--interactive only)* User chooses: Approve (ralph, team, or a goal-mode follow-up), Request changes, or Reject
 8. *(--interactive only)* On approval: invoke `$ralph` for sequential execution, `$team` for parallel team execution, or the selected goal-mode follow-up (`$ultragoal`, `$autoresearch-goal`, or `$performance-goal`) with the approved plan and matching success/evaluator context -- never implement directly. Preserve the explicit available-agent-types roster, reasoning-by-lane guidance, role/staffing allocation guidance, launch hints, and verification-path guidance from the approved plan for Ralph/team paths.
 
@@ -66,7 +66,7 @@ Follow the Plan skill's full documentation for consensus mode details.
 
 When ralplan outputs a final handoff or asks the user to choose a next lane, include product-facing goal-mode suggestions alongside the existing Ralph and team options:
 
-- `$ultragoal` — general goal-oriented follow-up when the plan should become one or more durable Codex goals with sequential completion tracking.
+- `$ultragoal` — **default goal-mode follow-up** for implementation or general goal-oriented follow-up plans that should become durable Codex/OMX goals with sequential completion tracking.
 - `$autoresearch-goal` — research-project follow-up when the plan centers on a question, literature/reference gathering, evaluator-backed research, or a professor/critic-style research deliverable.
 - `$performance-goal` — optimization/performance follow-up when the plan centers on speed, latency, throughput, memory, benchmark, or other measurable performance work.
 

package/skills/ultragoal/SKILL.md

@@ -9,7 +9,7 @@ Use when the user asks for `ultragoal`, `create-goals`, `complete-goals`, durabl
 
 ## Purpose
 
-`ultragoal` turns a brief into repo-native artifacts and then drives one goal at a time through Codex goal tools:
+`ultragoal` turns a brief into repo-native artifacts and then drives a Codex goal safely through goal tools. New plans default to an aggregate Codex goal for the whole ultragoal run while OMX tracks G001/G002 story progress in the ledger.
 
 - `.omx/ultragoal/brief.md`
 - `.omx/ultragoal/goals.json`
@@ -21,6 +21,7 @@ Use when the user asks for `ultragoal`, `create-goals`, `complete-goals`, durabl
    - `omx ultragoal create-goals --brief "<brief>"`
    - `omx ultragoal create-goals --brief-file <path>`
    - `cat <brief> | omx ultragoal create-goals --from-stdin`
+   - `omx ultragoal create-goals --codex-goal-mode per-story --brief "<brief>"` only when one fresh Codex thread per story is explicitly preferred
 2. Inspect `.omx/ultragoal/goals.json` and refine if needed.
 
 ## Complete goals
@@ -30,20 +31,23 @@ Loop until `omx ultragoal status` reports all goals complete:
 1. Run `omx ultragoal complete-goals`.
 2. Read the printed handoff.
 3. Call `get_goal`.
-4. If no active Codex goal exists, call `create_goal` with the printed payload.
-5. Complete that single goal only.
-6. Run a completion audit against the objective and real artifacts/tests.
-7. When complete, call `update_goal({status: "complete"})`, then call `get_goal` again for a fresh completion snapshot.
+4. If no active Codex goal exists, call `create_goal` with the printed payload. In aggregate mode, if the same aggregate Codex objective is already active, continue the current OMX story without creating a new Codex goal.
+5. Complete the current OMX story only.
+6. Run a completion audit against the story objective and real artifacts/tests.
+7. In aggregate mode, do **not** call `update_goal` for intermediate stories; checkpoint with a fresh `get_goal` snapshot whose aggregate objective is still `active`. On the final story only, call `update_goal({status: "complete"})`, then call `get_goal` again for a fresh `complete` snapshot.
 8. Checkpoint the durable ledger with that snapshot:
    `omx ultragoal checkpoint --goal-id <id> --status complete --evidence "<evidence>" --codex-goal-json <get_goal-json-or-path>`
 9. If blocked or failed, checkpoint failure:
    `omx ultragoal checkpoint --goal-id <id> --status failed --evidence "<blocker/evidence>"`
-10. Resume failed goals with `omx ultragoal complete-goals --retry-failed`.
+10. For legacy per-story completed-goal blockers, preserve the non-terminal blocker with:
+   `omx ultragoal checkpoint --goal-id <id> --status blocked --evidence "<completed legacy Codex goal blocks create_goal in this thread>" --codex-goal-json <get_goal-json-or-path>`
+11. Resume failed goals with `omx ultragoal complete-goals --retry-failed`.
 
 ## Constraints
 
 - The shell command cannot directly invoke Codex interactive `/goal`; it emits a model-facing handoff for the active Codex agent.
 - Never call `create_goal` when `get_goal` reports a different active goal.
-- Never call `update_goal` unless the current goal is actually complete.
+- Never call `update_goal` unless the aggregate run or legacy per-story goal is actually complete.
+- In aggregate mode, intermediate story checkpoints require a matching `active` Codex snapshot; final story completion requires a matching `complete` snapshot after `update_goal`.
 - Completion checkpoints require read-only Codex snapshot reconciliation: pass fresh `get_goal` JSON/path with `--codex-goal-json`; shell commands and hooks must not mutate Codex goal state.
 - Treat `ledger.jsonl` as the durable audit trail; checkpoint after every success or failure.

package/skills/wiki/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wiki
-description: Persistent markdown project wiki stored under .omx/wiki with keyword search and lifecycle capture
+description: Persistent markdown project wiki stored under repository omx_wiki with keyword search and lifecycle capture
 triggers: ["wiki add", "wiki lint", "wiki query", "wiki read", "wiki delete"]
 ---
 
@@ -42,9 +42,9 @@ wiki_refresh()
 `architecture`, `decision`, `pattern`, `debugging`, `environment`, `session-log`, `reference`, `convention`
 
 ## Storage
-- Pages: `.omx/wiki/*.md`
-- Index: `.omx/wiki/index.md`
-- Log: `.omx/wiki/log.md`
+- Pages: `omx_wiki/*.md`
+- Index: `omx_wiki/index.md`
+- Log: `omx_wiki/log.md`
 
 ## Cross-References
 Use `[[page-name]]` wiki-link syntax to create cross-references between pages.
@@ -54,4 +54,4 @@ At session end, discoveries can be captured as `session-log-*` pages. Configure
 
 ## Hard Constraints
 - No vector embeddings — query uses keyword + tag matching only
-- Wiki files remain local project state under `.omx/wiki/`
+- Wiki files are repository project knowledge under `omx_wiki/`; legacy `.omx/wiki/` is read-only compatibility input when no canonical wiki exists

package/src/scripts/__tests__/codex-native-hook.test.ts

@@ -24,6 +24,8 @@ import { writeSessionStart } from "../../hooks/session.js";
 import { resetTriageConfigCache } from "../../hooks/triage-config.js";
 import { executeStateOperation } from "../../state/operations.js";
 import { OMX_TMUX_HUD_OWNER_ENV } from "../../hud/reconcile.js";
+import { writePage } from "../../wiki/storage.js";
+import { WIKI_SCHEMA_VERSION } from "../../wiki/types.js";
 
 function nativeHookScriptPath(): string {
   return join(process.cwd(), "dist", "scripts", "codex-native-hook.js");
@@ -225,6 +227,8 @@ describe("codex native hook config", () => {
       "PreToolUse",
       "PostToolUse",
       "UserPromptSubmit",
+      "PreCompact",
+      "PostCompact",
       "Stop",
     ]);
 
@@ -511,9 +515,70 @@ describe("codex native hook dispatch", () => {
     assert.equal(mapCodexHookEventToOmxEvent("UserPromptSubmit"), "keyword-detector");
     assert.equal(mapCodexHookEventToOmxEvent("PreToolUse"), "pre-tool-use");
     assert.equal(mapCodexHookEventToOmxEvent("PostToolUse"), "post-tool-use");
+    assert.equal(mapCodexHookEventToOmxEvent("PreCompact"), "pre-compact");
+    assert.equal(mapCodexHookEventToOmxEvent("PostCompact"), "post-compact");
     assert.equal(mapCodexHookEventToOmxEvent("Stop"), "stop");
   });
 
+
+
+  it("returns bounded wiki context for PreCompact", async () => {
+    const cwd = await mkdtemp(join(tmpdir(), "omx-native-hook-precompact-"));
+    try {
+      writePage(cwd, {
+        filename: "architecture.md",
+        frontmatter: {
+          title: "Architecture",
+          tags: ["architecture"],
+          created: "2026-05-08T00:00:00.000Z",
+          updated: "2026-05-08T00:00:00.000Z",
+          sources: [],
+          links: [],
+          category: "architecture",
+          confidence: "high",
+          schemaVersion: WIKI_SCHEMA_VERSION,
+        },
+        content: "\n# Architecture\n\nCompaction-relevant architecture note.\n",
+      });
+
+      const result = await dispatchCodexNativeHook({
+        hook_event_name: "PreCompact",
+        cwd,
+        session_id: "sess-precompact",
+      });
+
+      assert.equal(result.hookEventName, "PreCompact");
+      assert.equal(result.omxEventName, "pre-compact");
+      const additionalContext = (result.outputJson as { hookSpecificOutput?: { additionalContext?: string } } | null)
+        ?.hookSpecificOutput?.additionalContext ?? "";
+      assert.match(additionalContext, /Wiki: 1 pages/);
+      assert.match(additionalContext, /architecture/);
+    } finally {
+      await rm(cwd, { recursive: true, force: true });
+    }
+  });
+
+  it("returns a PostCompact nudge to write compaction artifacts to omx_wiki", async () => {
+    const cwd = await mkdtemp(join(tmpdir(), "omx-native-hook-postcompact-"));
+    try {
+      const result = await dispatchCodexNativeHook({
+        hook_event_name: "PostCompact",
+        cwd,
+        session_id: "sess-postcompact",
+      });
+
+      assert.equal(result.hookEventName, "PostCompact");
+      assert.equal(result.omxEventName, "post-compact");
+      const additionalContext = (result.outputJson as { hookSpecificOutput?: { additionalContext?: string } } | null)
+        ?.hookSpecificOutput?.additionalContext ?? "";
+      assert.match(additionalContext, /PostCompact Nudge/);
+      assert.match(additionalContext, /omx_wiki/);
+      assert.match(additionalContext, /compaction artifacts/);
+    } finally {
+      await rm(cwd, { recursive: true, force: true });
+    }
+  });
+
   it("writes SessionStart state against the long-lived session owner pid and injects environment context", async () => {
     const cwd = await mkdtemp(join(tmpdir(), "omx-native-hook-session-start-"));
     try {
@@ -1101,7 +1166,12 @@ describe("codex native hook dispatch", () => {
       assert.ok(result.outputJson, "UserPromptSubmit should emit developer context");
       assert.match(JSON.stringify(result.outputJson), /skill: ralplan activated and initial state initialized at \.omx\/state\/sessions\/sess-1\/ralplan-state\.json; write subsequent updates via omx_state MCP\./);
 
-      const statePath = join(cwd, ".omx", "state", "skill-active-state.json");
+      assert.equal(
+        existsSync(join(cwd, ".omx", "state", "skill-active-state.json")),
+        false,
+        "session-scoped keyword activation should not write root skill-active-state.json",
+      );
+      const statePath = join(cwd, ".omx", "state", "sessions", "sess-1", "skill-active-state.json");
       assert.equal(existsSync(statePath), true);
       const state = JSON.parse(await readFile(statePath, "utf-8")) as {
         skill?: string;

package/src/scripts/codex-execution-surface.ts

@@ -6,6 +6,8 @@ type CodexHookEventName =
   | "PreToolUse"
   | "PostToolUse"
   | "UserPromptSubmit"
+  | "PreCompact"
+  | "PostCompact"
   | "Stop";
 
 type CodexHookPayload = Record<string, unknown>;

package/src/scripts/codex-native-hook.ts

@@ -70,7 +70,11 @@ import {
 import type { HookEventEnvelope } from "../hooks/extensibility/types.js";
 import { dispatchHookEventRuntime } from "../hooks/extensibility/runtime.js";
 import { reconcileHudForPromptSubmit } from "../hud/reconcile.js";
-import { onSessionStart as buildWikiSessionStartContext } from "../wiki/lifecycle.js";
+import {
+  onPostCompact as buildWikiPostCompactContext,
+  onPreCompact as buildWikiPreCompactContext,
+  onSessionStart as buildWikiSessionStartContext,
+} from "../wiki/lifecycle.js";
 import { readAutoresearchCompletionStatus, readAutoresearchModeStateForActiveDecision } from "../autoresearch/skill-validation.js";
 import { readRunState } from "../runtime/run-state.js";
 import { getRunContinuationSnapshot, shouldContinueRun } from "../runtime/run-loop.js";
@@ -99,6 +103,8 @@ type CodexHookEventName =
   | "PreToolUse"
   | "PostToolUse"
   | "UserPromptSubmit"
+  | "PreCompact"
+  | "PostCompact"
   | "Stop";
 
 type CodexHookPayload = Record<string, unknown>;
@@ -358,6 +364,8 @@ function readHookEventName(payload: CodexHookPayload): CodexHookEventName | null
     || raw === "PreToolUse"
     || raw === "PostToolUse"
     || raw === "UserPromptSubmit"
+    || raw === "PreCompact"
+    || raw === "PostCompact"
     || raw === "Stop"
   ) {
     return raw;
@@ -377,6 +385,10 @@ export function mapCodexHookEventToOmxEvent(
       return "post-tool-use";
     case "UserPromptSubmit":
       return "keyword-detector";
+    case "PreCompact":
+      return "pre-compact";
+    case "PostCompact":
+      return "post-compact";
     case "Stop":
       return "stop";
     default:
@@ -3010,7 +3022,27 @@ export async function dispatchCodexNativeHook(
     });
   }
 
-  if ((hookEventName === "SessionStart" && !skipCanonicalSessionStartContext) || hookEventName === "UserPromptSubmit") {
+  if (hookEventName === "PreCompact") {
+    const compactContext = buildWikiPreCompactContext({ cwd });
+    if (compactContext.additionalContext) {
+      outputJson = {
+        hookSpecificOutput: {
+          hookEventName,
+          additionalContext: compactContext.additionalContext,
+        },
+      };
+    }
+  } else if (hookEventName === "PostCompact") {
+    const compactContext = buildWikiPostCompactContext({ cwd });
+    if (compactContext.additionalContext) {
+      outputJson = {
+        hookSpecificOutput: {
+          hookEventName,
+          additionalContext: compactContext.additionalContext,
+        },
+      };
+    }
+  } else if ((hookEventName === "SessionStart" && !skipCanonicalSessionStartContext) || hookEventName === "UserPromptSubmit") {
     const additionalContext = hookEventName === "SessionStart"
       ? await buildSessionStartContext(cwd, canonicalSessionId || nativeSessionId, {
         hookEventName,