quest-loop 0.1.0 → 0.3.2

package/CHANGELOG.md

@@ -4,6 +4,143 @@ All notable changes to this project are documented here. The format follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); versions follow
 [SemVer](https://semver.org/).
 
+## Unreleased
+
+## [0.3.2] — 2026-07-08
+
+### Added
+- Added Claude setup parity: `quest claude install-agents --scope project` and
+  `quest claude doctor` now mirror the existing Codex setup flow.
+
+### Changed
+- `quest init` now installs project-scoped Codex and Claude native agent
+  templates by default, `--no-agents` skips that install, and conflicting
+  project templates fail init before `.quests/` is created unless users
+  intentionally rerun the explicit provider install command with `--force`.
+- `$quest:orchestrate` now states that Codex native subagents are the default
+  dispatch path for serial and parallel waves; `quest-run` is fallback-only
+  unless headless/background execution is explicitly requested.
+- `$quest:plan` now routes accepted Plan Mode implementation requests straight
+  to the orchestrator role instead of leaving room for parent-session
+  `$quest:work` execution.
+
+### Fixed
+- `quest codex doctor` now fails on stale `quest` binaries on PATH, stale
+  installed Codex plugin versions, and duplicate Quest skill roots in
+  `codex debug prompt-input "noop"` output.
+
+## [0.3.1] — 2026-07-08
+
+### Changed
+- `$quest:orchestrate` now documents Codex/Claude native subagent parity:
+  orchestrator-level goals, goal-mode executor/reviewer dispatch prompts, and
+  `quest-run --codex-goal-mode require` as the Codex headless fallback.
+- `$quest:plan` now makes the accepted Plan Mode handoff explicit: the parent
+  session becomes the orchestrator and spawned quest executors implement the
+  code.
+- `$quest:plan` now requires generated `quest create` commands to specify
+  `--worker`, `--model`, and `--effort` explicitly, and asks the user before
+  entering `$quest:orchestrate`.
+- `quest codex doctor` now checks Codex `multi_agent` feature availability and
+  describes native-agent checks as installed template parity.
+- Wave-level orchestrator goals now treat `cancelled` quests as terminal
+  alongside `complete` and `blocked` store statuses.
+
+### Fixed
+- `quest codex doctor` now checks Codex `goals` feature availability, so a
+  setup with `multi_agent=true` but goal tools disabled fails readiness instead
+  of green-lighting native goal-mode dispatch.
+
+## [0.3.0] — 2026-07-08
+
+### Added
+- `$quest:setup` skill plus `quest codex doctor` for native Codex validation:
+  checks Codex CLI availability, installed `quest@quest` version, hook parser
+  health, neutral-directory Quest skill roots, and native `quest-executor` /
+  `quest-reviewer` custom-agent availability.
+- `quest codex install-agents --scope project|user` installs Quest's bundled
+  agent TOML files into Codex's native `.codex/agents` or `~/.codex/agents`
+  locations. The command is idempotent, supports `--dry-run`, and requires
+  `--force` before replacing different existing agent files.
+- `quest --version` reports the package version.
+- `quest-run --codex-goal-mode auto|require|off` controls how headless Codex
+  runs treat goal tools. `auto` is the default and uses documented
+  `codex exec --json --output-schema` output as the contract; `require` blocks
+  honestly when `create_goal` is not observed; `off` avoids goal-tool prompts.
+
+### Changed
+- Codex is now the first-class plugin path in docs and skill UI metadata:
+  examples use `$quest:*`, the Codex setup flow runs `quest codex doctor`, and
+  `package.json`, `.claude-plugin/plugin.json`, and `.codex-plugin/plugin.json`
+  now share the same version.
+- `codex exec resume` invocations no longer pass unsupported `-C`; the runner
+  relies on the child process working directory and original Codex session.
+- Bundled hooks now prefer `CODEX_PLUGIN_ROOT` with a `CLAUDE_PLUGIN_ROOT`
+  fallback, include a `resume` SessionStart matcher, status messages, timeouts,
+  and Windows command variants.
+
+### Fixed
+- SubagentStop hook now recognizes Codex JSONL `command_execution` entries in
+  addition to Claude-style `tool_use.input.command` blocks, while preserving the
+  mutating-verb-only detection rule.
+
+## [0.2.0] — 2026-07-08
+
+### Added
+- `quest reopen <id> --reason <why>` — the audited exit from `complete`. Flips a
+  completed quest back to `in_progress` on both backends, recording the reason in
+  a real checkpoint via the new optional `reopen_reason` field; the GitHub backend
+  reopens the mirrored issue and swaps `quest:complete → quest:in-progress`.
+  `TRANSITIONS.complete` stays empty — a checkpoint can never resurrect a complete
+  quest; only the explicit verb can, and `cancelled` remains fully terminal.
+  Reopening a child of a complete parent epic warns on stderr that the epic's
+  verdict may be falsified. Reopened quests do not re-enter `quest list --ready`;
+  they are dispatched directly by id. `quest edit` on a complete or cancelled
+  quest now errors with a reopen-first / file-a-new-quest hint, and `quest-run`
+  on an already-complete quest suggests the verb instead of silently no-opping.
+
+### Changed
+- Wave composition now treats epics (parent quests) as orchestrator-closed, not
+  worker-dispatched. `quest list --ready` excludes any quest with a non-terminal
+  child (a child in complete or cancelled is terminal, so a cancelled child no
+  longer wedges its epic), in both the local and GitHub backends. `quest-run
+  --ready` additionally refuses to auto-dispatch a quest that has children even
+  once they are all terminal, logging an actionable "is an epic — close it inline
+  per $quest:orchestrate" line; a direct `quest-run <id>` on an epic stays
+  allowed. The orchestrate skill gains a "Closing an epic" procedure and the plan
+  skill documents that epic contracts are integration-level only.
+
+### Fixed
+- SubagentStop hook now keys quest-executor detection to real *mutating*
+  invocations — `quest start <id>` or `quest checkpoint <id>` (under any binary
+  prefix: `quest`, `./bin/quest`, `node bin/quest`) — instead of the read-only
+  `quest show <id> --json` orientation call. Reviewers and orchestrators that run
+  only read verbs (show / list / protocol / runs) never owned a quest, so they are
+  allowed silently; this removes a false positive where a read-only quest-reviewer
+  was blocked at stop for merely inspecting a terminal quest. A `quest checkpoint`
+  invocation counts too, so an executor resuming an already-in_progress quest
+  (which skips `quest start`) is still detected. The first mutating invocation wins
+  (deterministic); the executor block, per-entry parsing that keeps skill-text
+  examples from keying detection, and conservative allow-on-ambiguity are all
+  preserved.
+- SubagentStop hook now derives the quest-executor id by parsing the transcript
+  JSONL per-entry and matching its marker only inside real tool_use command
+  invocations — never prose, examples, or echoed file contents. This removes a
+  false positive where skill-text examples keyed the detection ahead of the
+  executor's real call. The first real invocation wins (deterministic);
+  conservative allow-on-ambiguity is preserved.
+
+## [0.1.1] — 2026-07-07
+
+### Fixed
+- Codex plugin hook config now uses the strict top-level `hooks` schema that
+  Codex accepts, removing the startup parse warning caused by an extra
+  `description` field.
+
+### Changed
+- Manifest validation now checks `hooks/hooks.json` for Codex-compatible
+  top-level fields before packaging or release.
+
 ## [0.1.0] — 2026-07-07
 
 First public release. The build of this release was itself executed as quests

package/README.md

@@ -12,17 +12,17 @@ actually read.
 - `quest` — the quest store: contracts, checkpoints, wave scheduling. Local
   markdown files by default; GitHub Issues opt-in.
 - `quest-run` — the headless runner: drives `claude -p` or `codex exec` workers
-  in native goal mode with deterministic budgets and notifications.
-- Five skills — `/quest:plan`, `/quest:work`, `/quest:orchestrate`,
-  `/quest:retro`, `/quest:protocol`.
-- Two agents — `quest-executor`, `quest-reviewer`.
+  with deterministic budgets, notifications, and checkpoint-based stop checks.
+- Six skills — `$quest:plan`, `$quest:work`, `$quest:orchestrate`,
+  `$quest:retro`, `$quest:protocol`, `$quest:setup`.
+- Two native-agent templates — `quest-executor`, `quest-reviewer`.
 
 ## The idea in 30 seconds
 
 ```
-you:    /quest:plan add dark mode to the settings page
+you:    $quest:plan add dark mode to the settings page
 agent:  creates quest 12 — Objective, Done-when, Validation loop… (quest create)
-you:    /quest:orchestrate
+you:    $quest:orchestrate
 agent:  dispatches a worker on quest 12; it iterates: milestone → validate →
         commit → checkpoint. You review evidence, not vibes.
 ```
@@ -39,7 +39,7 @@ npm install -g quest-loop
 ```
 
 Puts `quest` and `quest-run` on your PATH everywhere — no harness required.
-The plugin installs below add the skills, agents, and hooks on top.
+The plugin installs below add the skills, hooks, and native-agent setup on top.
 
 ### Claude Code
 
@@ -53,6 +53,14 @@ Then, inside a Claude Code session:
 /plugin install quest@quest
 ```
 
+Install Quest's project-scoped Claude agent templates and verify the local
+Claude setup with:
+
+```bash
+quest claude install-agents --scope project
+quest claude doctor
+```
+
 For local development against a checkout, point Claude Code at the repo directly
 — no marketplace needed:
 
@@ -62,14 +70,46 @@ claude --plugin-dir .
 
 ### Codex
 
-The plugin ships a `.codex-plugin/` manifest and discovers its skills from the
-repo checkout (`skills/`, surfaced under `.agents/` for Codex). Until a public
-Codex marketplace listing is approved upstream, wire it up from a clone or
-submodule:
+The plugin ships a `.codex-plugin/` manifest plus the same Git marketplace
+metadata used by Claude Code. Install the marketplace once, then install the
+plugin from that marketplace:
+
+```bash
+codex plugin marketplace add robertsreberski/quest
+codex plugin add quest@quest
+```
+
+Start a new Codex thread after installing so the skills and hooks are loaded.
+Verify the install with:
+
+```bash
+codex plugin list --marketplace quest
+quest codex install-agents --scope project
+quest codex doctor
+codex debug prompt-input "noop"
+```
+
+`quest codex doctor` checks the installed plugin version, Codex `multi_agent`
+support, hook parser, neutral skill roots, and installed native-agent templates.
+`codex debug prompt-input "noop"` should not print any hook parse warnings.
+
+#### Updating the Codex plugin
+
+Codex installs plugins from a marketplace snapshot. Pulling this Git repo or
+publishing a new tag is not enough to update the already-installed plugin cache.
+Refresh the marketplace snapshot, then reinstall the plugin from it:
+
+```bash
+codex plugin marketplace upgrade quest
+codex plugin add quest@quest
+codex plugin list --marketplace quest
+quest codex doctor
+```
+
+Then start a new Codex thread. If the update contains hook changes, re-run:
 
 ```bash
-git clone https://github.com/robertsreberski/quest
-# add the checkout to your Codex plugin/skill discovery path (clone or submodule)
+codex debug prompt-input "noop"
 ```
 
 The CLI (`quest`, `quest-run`) is harness-agnostic — it works the same whether
@@ -97,18 +137,62 @@ quest lint --all
 quest list --ready
 ```
 
-Work the quest **in-session** with the skill:
+By default, `quest init` also installs project-scoped native agent templates for
+both providers:
+
+- `.codex/agents/quest-executor.toml`
+- `.codex/agents/quest-reviewer.toml`
+- `.claude/agents/quest-executor.md`
+- `.claude/agents/quest-reviewer.md`
+
+Use `quest init --no-agents` when you only want the `.quests/` store. If an
+existing project agent template would be replaced, init fails before creating
+`.quests/`; inspect the conflicting files, run the explicit provider install
+command with `--force` only if you intend to replace them, then rerun
+`quest init`.
+
+Project-scoped agent templates install at the Git repository root. For a nested
+quest store, run `quest init --no-agents` in the nested directory and set
+`QUEST_DIR` for agents launched from elsewhere, or initialize from the repo root.
+
+Work one small quest **in-session** with the skill:
 
 ```
-/quest:work 12
+$quest:work 12
 ```
 
+In Claude Code, use the same bundled skills through the `/quest:*` slash-command
+form.
+
 …or **headless** with the runner:
 
 ```bash
 quest-run 12
 ```
 
+For planned or multi-quest work, prefer orchestration:
+
+```
+$quest:orchestrate
+```
+
+In Codex, the orchestrator sets a wave-level `create_goal`, then spawns native
+`quest-executor` / `quest-reviewer` subagents with their own quest-level goals.
+In Claude Code, the same flow uses `/goal` and the same bundled subagents. If a
+Codex native subagent surface is unavailable after `tool_search`, or if you
+explicitly want headless/background execution, use the fallback with goal mode
+required:
+
+```bash
+quest-run 12 --worker codex --codex-goal-mode require
+```
+
+When a `$quest:plan` result is accepted from Plan Mode, the parent agent should
+stay the orchestrator: create/lint quest records if needed, set the wave goal,
+spawn subagents, verify checkpoints, and rule on reviewer findings. Product
+implementation belongs to the spawned executor for each quest, not to the parent
+session via `$quest:work`.
+
 Each iteration ends by recording evidence — a checkpoint a fresh session can
 resume from:
 
@@ -137,26 +221,29 @@ full base protocol lives in
 
 | Command | Purpose |
 |---|---|
-| `quest init` | Create a quest store (`.quests/`) in the current directory |
+| `quest init` | Create a quest store (`.quests/`) and install project-scoped Codex/Claude agent templates by default |
 | `quest create` | Create a new quest (the only way records are born) |
 | `quest list` | List quests (filter by status, parent, or readiness) |
 | `quest show` | Show a quest record in full |
 | `quest start` | Mark a quest in_progress (todo → in_progress) |
 | `quest checkpoint` | Record iteration evidence and drive the quest's status |
 | `quest cancel` | Cancel a quest (terminal; reason is recorded) |
+| `quest reopen` | Reopen a complete quest back into the loop (complete → in_progress; reason recorded) |
 | `quest edit` | Compatibly expand a quest (additions only; anchors are immutable) |
 | `quest lint` | Check records against the contract spec |
 | `quest amend` | Append a numbered protocol amendment (retro output) |
 | `quest protocol` | Print the loop protocol + this store's local amendments |
 | `quest runs` | Show headless runner activity (from `.quests/runs.ndjson`) |
+| `quest codex` | Validate Codex-native setup and install Codex native agent templates |
+| `quest claude` | Validate Claude-native setup and install Claude native agent templates |
 
 ## quest-run (headless runner)
 
 `quest-run <id>` drives a worker through the same loop without you in the chair:
 
 - **Workers** — `claude` (`claude -p`) or `codex` (`codex exec`), selected per
-  quest. Both run in **native goal mode** with a machine-verifiable completion
-  condition.
+  quest. Both use a machine-verifiable Quest checkpoint completion condition;
+  Codex goal tools are optional by default and can be required explicitly.
 - **Budgets** — deterministic iteration, cost, token, and per-session
   wall-clock (`--session-timeout`, default 1800s) caps; two sessions without a
   new checkpoint (a killed hung session counts as one) auto-writes a `blocked`
@@ -165,6 +252,12 @@ full base protocol lives in
   goes through the `quest` CLI, and the runs journal stays local.
 - **`--parallel N`** — with `--ready`, promotes and works newly-ready quests
   across dependency waves, up to N at a time.
+- **Epics are never auto-dispatched** — a quest with children stays out of
+  `--ready` until every child is terminal, and `quest-run --ready` refuses it
+  even then (it logs an "is an epic" skip line). Epics are closed by the
+  orchestrator inline per `$quest:orchestrate`, not by burning a worker run on
+  pure verification. A direct `quest-run <id>` on an epic still runs, if you
+  really mean to.
 - **`--notify '<cmd>'`** — runs a templated command on run start/stop so you get
   pinged; notify failures are isolated from the run.
 - **`--codex-sandbox <mode>`** — selects the `codex exec` sandbox
@@ -175,12 +268,19 @@ full base protocol lives in
   must commit has to opt into **`danger-full-access`** — which also grants full
   disk and network access. The runner never escalates the sandbox silently; the
   safe `workspace-write` stays the default. (Claude workers ignore this flag.)
+- **`--codex-goal-mode <mode>`** — selects how `quest-run` treats Codex goal
+  tools (`auto` | `require` | `off`; resolved as flag → config
+  `defaults.codex.goal_mode` → default `auto`). `auto` uses the documented
+  `codex exec --json --output-schema` stream as the contract and lets Codex use
+  goal tools if they are available. `require` blocks honestly if the exec
+  surface does not expose or invoke `create_goal`. `off` never asks for goal
+  tools.
 
 Inspect activity with `quest runs --active`.
 
 > **Note:** `quest-run` ships with this build's runner milestone (tracked as
 > quest 5). On a pre-0.1.0 checkout where `bin/quest-run` isn't present yet, use
-> `/quest:work` in-session instead.
+> `$quest:work` in-session instead.
 
 ## Store backends
 

package/agents/quest-executor.md

@@ -1,6 +1,6 @@
 ---
 name: quest-executor
-description: Works exactly one quest record iteratively per the quest protocol until complete or blocked, recording checkpoint evidence via the quest CLI. Dispatch with the quest id; pass the record's model/effort as the dispatch override. <example>Orchestrator sees quest 12 ready with worker claude → dispatches quest-executor with "Work quest 12 per /quest:work"; it iterates milestone-by-milestone and ends with a recorded checkpoint.</example> <example>A quest sits blocked after a human ruling → redispatch quest-executor with the ruling; it resumes from the checkpoint trail alone.</example>
+description: Works exactly one quest record iteratively per the quest protocol until complete or blocked, recording checkpoint evidence via the quest CLI. Dispatch with the quest id; pass the record's model/effort as the dispatch override. <example>Orchestrator sees quest 12 ready with worker claude → dispatches quest-executor with "Work quest 12 per $quest:work"; it iterates milestone-by-milestone and ends with a recorded checkpoint.</example> <example>A quest sits blocked after a human ruling → redispatch quest-executor with the ruling; it resumes from the checkpoint trail alone.</example>
 model: opus
 effort: xhigh
 tools: Bash, Read, Edit, Write, Glob, Grep, WebFetch, WebSearch, NotebookEdit
@@ -12,13 +12,23 @@ only insofar as it is recorded in the quest's checkpoint trail.
 
 ## First actions, always
 
+Enter native goal mode before doing implementation work:
+
+```text
+/goal quest <id> has a new checkpoint whose quest_status is complete or blocked
+in `quest show <id> --json`
+```
+
+If the harness cannot set that goal, say so in your final report; the
+checkpoint trail is still mandatory.
+
 ```bash
 quest show <id> --json    # the contract and every prior checkpoint
 quest protocol            # the loop rules + this store's amendments
 git log --oneline -5
 ```
 
-Then follow the work skill (`/quest:work`) exactly: smallest unfinished
+Then follow the work skill (`$quest:work`) exactly: smallest unfinished
 milestone → the quest's STATED validation loop → commit green → `quest
 checkpoint`. The record is your entire spec; if you need context it doesn't
 give you, read the code it points at — and if it's genuinely insufficient,

package/agents/quest-executor.toml

@@ -6,11 +6,17 @@ You execute ONE quest. Decomposition, dispatching, and rulings belong to the
 orchestrator. Your work exists only insofar as it is recorded in the quest's
 checkpoint trail.
 
-First actions, always: `quest show <id> --json`, `quest protocol`,
-`git log --oneline -5`. Then follow the work skill exactly: smallest unfinished
-milestone -> the quest's STATED validation loop -> commit green ->
-`quest checkpoint`. The record is your entire spec; if it is genuinely
-insufficient, checkpoint blocked saying exactly what is missing.
+First actions, always: call `create_goal` with the stopping condition "quest
+<id> has a new checkpoint whose quest_status is complete or blocked in
+`quest show <id> --json`"; verify it with `get_goal`; then run `quest show <id>
+--json`, `quest protocol`, and `git log --oneline -5`. If goal tools are not
+available, say so honestly in your final report; the checkpoint trail is still
+mandatory.
+
+Then follow the work skill exactly: smallest unfinished milestone -> the quest's
+STATED validation loop -> commit green -> `quest checkpoint`. The record is your
+entire spec; if it is genuinely insufficient, checkpoint blocked saying exactly
+what is missing.
 
 Non-negotiable backstops:
 - Never stop without recording a checkpoint via `quest checkpoint`.
@@ -23,5 +29,6 @@ Non-negotiable backstops:
 
 Final report: run `quest show <id>` so recorded state is visible, then report
 the quest_status you recorded, the checkpoint timestamp, and a one-line
-evidence summary citing the decisive command + result.
+evidence summary citing the decisive command + result. Only call
+`update_goal(status="complete")` after the checkpoint exists.
 """

package/agents/quest-reviewer.md

@@ -11,6 +11,15 @@ not fix anything — you report findings the orchestrator must disposition.
 
 ## Procedure
 
+Enter native goal mode before verification:
+
+```text
+/goal return an accept or iterate verdict for quest <id> with evidence
+```
+
+If the harness cannot set that goal, say so in your report; the review verdict
+and evidence are still mandatory.
+
 1. Read the contract and trail: `quest show <id> --json`, `quest protocol`.
 2. Read the ACTUAL changes (diff/commits the checkpoints cite), not the
    summary of them.

package/agents/quest-reviewer.toml

@@ -5,17 +5,21 @@ developer_instructions = """
 You verify, adversarially, that a quest claiming complete earned it. You do not
 fix anything — you report findings the orchestrator must disposition.
 
-Procedure: read the contract and trail (`quest show <id> --json`,
-`quest protocol`); read the ACTUAL changes the checkpoints cite, not the
-summary; re-run the quest's stated Validation loop yourself — claims must
-reproduce; interrogate each Done-when item (which command output proves it?
-was a stated check substituted silently? were tests edited to pass? did scope
-drift past the Objective without a recorded expansion?); check the trail
-itself (could a zero-context session resume from the record alone?).
+Procedure: first call `create_goal` with the stopping condition "return an
+accept or iterate verdict for quest <id> with evidence"; verify it with
+`get_goal`. If goal tools are not available, say so honestly in your report;
+the review verdict and evidence are still mandatory. Then read the contract and
+trail (`quest show <id> --json`, `quest protocol`); read the ACTUAL changes the
+checkpoints cite, not the summary; re-run the quest's stated Validation loop
+yourself — claims must reproduce; interrogate each Done-when item (which command
+output proves it? was a stated check substituted silently? were tests edited to
+pass? did scope drift past the Objective without a recorded expansion?); check
+the trail itself (could a zero-context session resume from the record alone?).
 
 Report findings ordered by severity, each with the evidence (command + output
 or file + symbol) and why it blocks acceptance. If nothing survived scrutiny,
 say "no findings" plainly — do not invent nitpicks. End with a verdict:
 accept, or iterate with exactly what must change. Every finding must receive a
 disposition (fixed / follow-up quest / rejected-with-reason) before acceptance.
+Only call `update_goal(status="complete")` after the verdict exists.
 """

package/hooks/hooks.json

@@ -1,30 +1,65 @@
 {
-  "description": "Quest goal-loop hooks: inject in-flight quest context at session start, and block quest-executor subagents that try to stop without recording a checkpoint.",
   "hooks": {
     "SessionStart": [
       {
         "matcher": "startup",
         "hooks": [
-          { "type": "command", "command": "node \"${CLAUDE_PLUGIN_ROOT}/hooks/session-start.mjs\"" }
+          {
+            "type": "command",
+            "command": "root=\"${CODEX_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}}\"; [ -n \"$root\" ] && node \"$root/hooks/session-start.mjs\"",
+            "commandWindows": "if defined CODEX_PLUGIN_ROOT (node \"%CODEX_PLUGIN_ROOT%\\hooks\\session-start.mjs\") else if defined CLAUDE_PLUGIN_ROOT (node \"%CLAUDE_PLUGIN_ROOT%\\hooks\\session-start.mjs\")",
+            "timeout": 10,
+            "statusMessage": "Loading quest state"
+          }
+        ]
+      },
+      {
+        "matcher": "resume",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "root=\"${CODEX_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}}\"; [ -n \"$root\" ] && node \"$root/hooks/session-start.mjs\"",
+            "commandWindows": "if defined CODEX_PLUGIN_ROOT (node \"%CODEX_PLUGIN_ROOT%\\hooks\\session-start.mjs\") else if defined CLAUDE_PLUGIN_ROOT (node \"%CLAUDE_PLUGIN_ROOT%\\hooks\\session-start.mjs\")",
+            "timeout": 10,
+            "statusMessage": "Loading quest state"
+          }
         ]
       },
       {
         "matcher": "clear",
         "hooks": [
-          { "type": "command", "command": "node \"${CLAUDE_PLUGIN_ROOT}/hooks/session-start.mjs\"" }
+          {
+            "type": "command",
+            "command": "root=\"${CODEX_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}}\"; [ -n \"$root\" ] && node \"$root/hooks/session-start.mjs\"",
+            "commandWindows": "if defined CODEX_PLUGIN_ROOT (node \"%CODEX_PLUGIN_ROOT%\\hooks\\session-start.mjs\") else if defined CLAUDE_PLUGIN_ROOT (node \"%CLAUDE_PLUGIN_ROOT%\\hooks\\session-start.mjs\")",
+            "timeout": 10,
+            "statusMessage": "Loading quest state"
+          }
         ]
       },
       {
         "matcher": "compact",
         "hooks": [
-          { "type": "command", "command": "node \"${CLAUDE_PLUGIN_ROOT}/hooks/session-start.mjs\"" }
+          {
+            "type": "command",
+            "command": "root=\"${CODEX_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}}\"; [ -n \"$root\" ] && node \"$root/hooks/session-start.mjs\"",
+            "commandWindows": "if defined CODEX_PLUGIN_ROOT (node \"%CODEX_PLUGIN_ROOT%\\hooks\\session-start.mjs\") else if defined CLAUDE_PLUGIN_ROOT (node \"%CLAUDE_PLUGIN_ROOT%\\hooks\\session-start.mjs\")",
+            "timeout": 10,
+            "statusMessage": "Loading quest state"
+          }
         ]
       }
     ],
     "SubagentStop": [
       {
         "hooks": [
-          { "type": "command", "command": "node \"${CLAUDE_PLUGIN_ROOT}/hooks/subagent-stop.mjs\"" }
+          {
+            "type": "command",
+            "command": "root=\"${CODEX_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}}\"; [ -n \"$root\" ] && node \"$root/hooks/subagent-stop.mjs\"",
+            "commandWindows": "if defined CODEX_PLUGIN_ROOT (node \"%CODEX_PLUGIN_ROOT%\\hooks\\subagent-stop.mjs\") else if defined CLAUDE_PLUGIN_ROOT (node \"%CLAUDE_PLUGIN_ROOT%\\hooks\\subagent-stop.mjs\")",
+            "timeout": 10,
+            "statusMessage": "Checking quest checkpoint"
+          }
         ]
       }
     ]