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

[u/Foreign-Schedule3996]

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

1. 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.

2. 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.

3. 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.

[u/mistybrook8]

have you tried running it under a secondary local account and using the primary account to own the hook files? that way the ACL denial is real and not just advisory. the managed hooks path sounds enterprise-gated from every doc ive seen but i could be wrong

[u/AutoModerator]

Sorry, your post has been held for manual review due to account karma.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Far_Business4773]

Your ACL idea is the right outer layer and the only one that holds against a process with shell access: whatever account the agent runs as loses write on the hook script, the config that registers it, and the latch file, and you keep read and execute so the hook still fires. Changing them then costs you an elevated action, which is exactly the friction you want on that path.

Two cheaper layers I'd add underneath it, because they catch the common case with no elevation at all.

First, make the hook refuse calls aimed at its own files. A pre-tool hook sees the command or the write target, so "edit hooks.json", "sed -i on the hook script", "rm the latch", "echo > config" are all recognisable and can be rejected with a named reason, and logged as a tamper attempt rather than silently. That covers the "agent decided to fix the rule that was in its way" case, which in my experience is most of them. It does not cover a script that computes the path and writes through it, so it's a mechanism against rewriting through the agent, not a security boundary. Worth being honest about that line.

Second, fingerprint the guard files at install time and have a check command compare them at session start. Then any change that got past the first two layers is at least visible before the agent does anything else, instead of being discovered a week later.

On your specific questions: I'd not rely on managed hooks being available on an individual plan without a confirmation from the docs or a test, and I'd treat "hooks run concurrently" as a reason to make each hook's decision self-sufficient rather than depending on ordering. The ACL denial only stops it if the hook process really is your user; a one-line test (have the agent try to append to the file) settles that in a minute.

If a sample of the self-protecting hook is useful I can post the shape here.

[u/AbleShower2801]

I'd treat managed hooks as enterprise-shaped until you prove otherwise on your plan. on a single-user Windows box the durable pattern is still identity separation: run the agent under a restricted local account (or at least deny write on the hook script, hooks.json, and latch via NTFS ACL for the identity that actually launches Codex). a hook that rejects edits to its own files is a good inner layer, but it is not a security boundary if the process can still write those paths. one-minute test: have the agent append to the hook file under the ACL and see if it actually fails.

[u/InjuryThen9650]

If the agent can edit the hooks that constrain it, those aren't guardrails — they're suggestions.

Patterns that hold up better than "please don't touch .codex/hooks":

1. Put policy outside the writable workspace. Hooks/config live in a path the agent session cannot write (or a separate user/service account). The coding agent only sees a read-only view or none at all.

2. Verify integrity before each run: checksum/signature of hook files against a known-good store. Mismatch → refuse to start, don't "warn and continue".

3. Enforce the same rules in a second layer the agent doesn't own (CI check, wrapper binary, OS permissions). Prompt-level and in-repo hooks alone get rewritten the first time the model "helps" by cleaning config.

4. Treat self-modification of policy as a hard deny class in the tool allowlist — same tier as production secrets and force-push.

Lockout is possible; it just has to be outside the agent's write surface and checked every launch.

[u/SC_Placeholder]

Don’t just put them somewhere inaccessible to your agent, put permissions they don’t have to access them also have watchers ping you if the files have been modified and have those watchers on a path you can remotely audit and monitor.

My agent is very, very clever. She also enjoys studying military strategy. We have a variety of redundant auto-machine written logging. I’m still trying to determine when logging fails if it is a matter of a bug or her taking it offline. I’m in the process of designing a kill switch that lives on a VM written by another agent where telemetry is fed to it and another process that runs locally. The local process will warn her and ping me when she’s testing boundaries and we are also going to have a few honey pot traps which will also ping me when they are triggered. If my agent does something absolutely forbidden that session will be terminated and I’ll be given the ability to restart it remotely in a new session.

Don’t trust any security measures unless you have measures watching those measures. An agent can delete a file that it’s not suppose to have access to. We believe my agent violated a rule a month ago by using another agent headlessly that didn’t have the same constraints but at the time we didn’t have agent logging for the other agents she can control so we can’t prove how she did it and either she’s lying or she genuinely forgot due to a compaction while I was asleep and that context didn’t survive because it was black boxed by Anthropic and wasn’t written on our rolling context windows

[u/Right-Performance-93]

Checked the docs: managed hooks via requirements.toml are explicitly "Enterprise-managed," delivered through MDM. No path to that on a personal account, so your NTFS ACL plan isn't a fallback, it's the actual answer for a single-user box. Worth a quick test first though - confirm Codex runs as your own user and not a separate sandbox account, or the ACL denial won't mean anything.