Can an AI coding agent be locked out of modifying its own guardrail hooks? (OpenAI Codex CLI)

Goal

I run AI coding agents locally on Windows and want a "hardstop" I can trigger at any time - a single keystroke that immediately blocks the agent from doing anything further until I clear it. I have this working for one agent as a UserPromptSubmit hook: typing exactly "h" arms a latch file, "c" clears it, and while the latch exists every prompt is blocked before the model sees it.

I now want the same thing for Codex, but hardened.

The problem

The agent runs under my own user account. Anything my user can write, the agent can write - including its own hook script, the hooks.json that registers it, and the latch file itself. So the guardrail is only as strong as the agent's willingness to respect it, which is not a guarantee. I have already had files in this setup modified without my approval.

Instruction-level policy (system prompt / AGENTS.md rules telling it not to touch these files) demonstrably does not hold. I need a mechanical boundary, not a promise.

What I have built or considered

- Wrapper + policy design - an output gate that mechanically checks replies, plus instruction files. Works for what it does, but it cannot protect itself: the agent can edit the policy files.

- Codex managed hooks - the docs describe hooks from requirements.toml as "marked as managed, trusted by policy, and can't be disabled from the user hook browser", with allow_managed_hooks_only = true skipping user/project/session/plugin hooks. This looks like exactly what I want.

- NTFS ACLs - deny write/delete on the hook script and hooks.json to whatever identity the agent runs as, keeping read+execute so the hook still fires. Changes would then require an elevated (UAC) action by me.

Questions

- Does the requirements.toml managed-hooks path work on a personal/individual account, or does it require an enterprise/MDM deployment? The docs frame it as enterprise-managed and I cannot tell whether it is plan-gated.

- Does Codex CLI run hooks as the logged-in user, or under a separate sandbox account? That determines whether an ACL denial actually stops it.

- Codex docs note that multiple hooks for the same event "are launched concurrently, so one hook can't prevent another matching hook from starting". Does a decision: block from one UserPromptSubmit hook still reliably stop the turn?

- Is there a better pattern for this generally - making an agent's own kill switch tamper-proof against the agent, on a single-user machine, without paying for an enterprise tier?

Any pointers to the right docs or prior art appreciated.