[PR] feat(vetted-ops): let the ~ spelling reach Codex rules safely [magpie]

["potiuk (via GitHub)" <gi...@apache.org>]

potiuk opened a new pull request, #1670:
URL: https://github.com/apache/magpie/pull/1670

   Skills invoke the dispatcher as `uv run --project ~/.claude/magpie/vetted-ops vetted-op-read …`, which the Codex rules added in #1649 never match, so every read-only vetted operation prompts under Codex. Allowing `~` in the rules would not be a fix:
   
   - Codex's plain-command parser rejects any word containing `~` (`codex-rs/shell-command/src/bash.rs`), so a shell-string command with `~` never reaches a prefix rule at all.
   - `~` in an argv-form command would be worse: `uv` does not expand it and treats `~/…` as a relative directory, so an agent-created `./~/.claude/magpie/vetted-ops` would run with an `allow` and a sandbox bypass. In shell form, `~` follows `HOME`, which an earlier command can reassign.
   
   So the rules stay absolute-only, and the `~` is resolved before they run:
   
   - **`vetted-ops-codex-rules --hook`** prints a Codex-only `PreToolUse` hook registration with the same absolute stable path the rules name (`--stable-path`, fixed at render time). It goes in the user's `~/.codex/config.toml`, after review, like the rules.
   - **The hook rewrites one case only:** a command that is exactly one `vetted-op-read` call in the `~` spelling, with plain or simply quoted arguments. Write entry points (`vetted-op`, `vetted-op-tracker`) and anything chained, redirected, substituted or multi-line are left untouched.
   - **It grants nothing.** In Codex 0.163 the hook's `allow` only carries `updatedInput`: a hook result is either continue (with an optional rewrite) or blocked, and the rewritten command then goes through the native rules and approval. Even if `allow` were read as an approval, the hook could only let through the lone read the rules already allow.
   - **Codex only.** Claude Code reads the same `allow` as a permission grant, so the hook is registered in Codex config only, and as a backstop stays silent unless the event carries Codex's `turn_id` and `model` fields.
   
   Tests cover the rewrite, 24 inputs it must leave alone (writes, `;`/`&&`/pipes, redirection, `$(…)`, backticks, heredocs, quoted/escaped/lookalike paths), the `HOME`-independent fallback, the output contract (including a Claude-style event that must stay silent), and a round trip through the real `codex execpolicy check`: the skill's `~` command matches nothing, and its rewrite matches the absolute `allow` rule.
   
   Not verified end to end in a live Codex session (that needs a model run); the hook/approval interaction is from the 0.163.0 source.
   
   ---
   
   Second read: roborev (claude-code), iterated until it passed; a background security review shaped the lone-read restriction.
   
   Generated-by: Claude Opus 5
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] feat(vetted-ops): let the ~ spelling reach Codex rules safely [magpie]

["potiuk (via GitHub)" <gi...@apache.org>]

potiuk merged PR #1670:
URL: https://github.com/apache/magpie/pull/1670


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org