From d75448443d0c7de0fe35a0fdb758e2b0c1db7eef Mon Sep 17 00:00:00 2001 From: Cursor Agent Date: Fri, 2 Oct 2026 08:11:22 +0000 Subject: [PATCH] Keep the Codex processor fixture as the first JSON example. The release check reads the first JSON fence in the Codex RTK reference as the processor fixture. The hook metadata example was added above it, so hook_event_name was missing. Move Processor and live execution ahead of Hook metadata and trust. Co-authored-by: Dennis Geldmacher --- skills/rtk-setup/references/codex.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/skills/rtk-setup/references/codex.md b/skills/rtk-setup/references/codex.md index 48a299f..1d7e38a 100644 --- a/skills/rtk-setup/references/codex.md +++ b/skills/rtk-setup/references/codex.md @@ -6,6 +6,20 @@ RTK 0.44.2 was tested with instruction-based Codex integration. RTK 0.50.0 provi ## Native hook path +### Processor and live execution + +When supported, inspect registration, enabled/trusted hook state in Codex, and `rtk hook check --agent codex 'git status --short'`. Exercise `rtk hook codex` with this RTK 0.50.0 processor fixture on stdin: + +```json +{"hook_event_name":"PreToolUse","permission_mode":"default","tool_name":"Bash","tool_input":{"command":"git status --short","timeout_ms":1000}} +``` + +The fixture does not execute the command. `hook_event_name`, the shell tool name, and a supported `permission_mode` matter: omitting `permission_mode` makes RTK 0.50.0 pass through without a rewrite. If the actual host sends a different payload, verify that payload against the installed processor rather than inventing compatibility. + +Expect `hookSpecificOutput.hookEventName: PreToolUse`, `hookSpecificOutput.updatedInput.command: rtk git status --short`, and `hookSpecificOutput.permissionDecision: allow`, with other input fields retained. These are Codex fields, not Cursor's `updated_input` and `permission`. Protocol-level `allow` is required for Codex's replacement input; it does not prove that the rewritten command bypassed or satisfied native approvals and sandbox checks. Do not copy Cursor's `ask` response into Codex or interpret unsupported fields as an enforced approval gate. + +For a valid, supported, policy-permitted fixture, missing replacement input remains failed or unverified. Unsupported inputs or policy-based passthrough are separate observations. A successful processor result proves only the processor. In a fresh actual Codex task, observe an unprefixed finite shell call, its replacement/executed command and native permission result. Do not relax permissions or bypass hook trust for the smoke. Then check `rtk gain --history`; it proves RTK execution, not automatic rewriting by itself. + ### Hook metadata and trust Before asking the user to trust the hook, explain in their language that `rtk hook codex` runs the local RTK program before shell calls and rewrites supported commands to use RTK's compact output. Codex requires trust for automatic hook execution. Metadata does not replace that trust review or establish approval of a rewritten command. @@ -26,20 +40,6 @@ Recheck the metadata after later authorized native setup or integration updates `statusMessage` describes the hook while it runs; it is not a documented hook name. During a separately commissioned local setup or live smoke, record the trust-dialog title and execution status display separately, with the Codex version and observed evidence. A dialog still titled "Hook 1" is compatible with successful metadata setup; mark any unobserved display as `unverified` and do not claim the title changed from configuration alone. A metadata-only source change does not authorize a personal configuration change, deployment, or extra model invocation. -### Processor and live execution - -When supported, inspect registration, enabled/trusted hook state in Codex, and `rtk hook check --agent codex 'git status --short'`. Exercise `rtk hook codex` with this RTK 0.50.0 processor fixture on stdin: - -```json -{"hook_event_name":"PreToolUse","permission_mode":"default","tool_name":"Bash","tool_input":{"command":"git status --short","timeout_ms":1000}} -``` - -The fixture does not execute the command. `hook_event_name`, the shell tool name, and a supported `permission_mode` matter: omitting `permission_mode` makes RTK 0.50.0 pass through without a rewrite. If the actual host sends a different payload, verify that payload against the installed processor rather than inventing compatibility. - -Expect `hookSpecificOutput.hookEventName: PreToolUse`, `hookSpecificOutput.updatedInput.command: rtk git status --short`, and `hookSpecificOutput.permissionDecision: allow`, with other input fields retained. These are Codex fields, not Cursor's `updated_input` and `permission`. Protocol-level `allow` is required for Codex's replacement input; it does not prove that the rewritten command bypassed or satisfied native approvals and sandbox checks. Do not copy Cursor's `ask` response into Codex or interpret unsupported fields as an enforced approval gate. - -For a valid, supported, policy-permitted fixture, missing replacement input remains failed or unverified. Unsupported inputs or policy-based passthrough are separate observations. A successful processor result proves only the processor. In a fresh actual Codex task, observe an unprefixed finite shell call, its replacement/executed command and native permission result. Do not relax permissions or bypass hook trust for the smoke. Then check `rtk gain --history`; it proves RTK execution, not automatic rewriting by itself. - ## Instruction-based path When native rewriting is unavailable or not configured, verify the active `AGENTS.md` reference and operational instructions. Run one approved finite command directly as `rtk `, then inspect `rtk gain --history`. Report this as direct RTK execution and leave automatic rewriting unverified. In this path, setup examples or a Verification section apply to setup/troubleshooting, not every task.