Context: an unattended omp agent runs under a root-owned --config overlay with tools.approvalMode: yolo, bash.patterns deny/prompt rules, and tools.approval.eval: prompt so eval can't route around the patterns. The model kept choosing eval anyway, despite instructions saying "eval always asks; use bash", so every Python cell became an approval card and the bot stalled.
Measured on omp 18.16.0 (macOS) in print mode with an overlay containing only approvalMode: yolo and bash.patterns: [{match: "echo canary*", approval: deny}]:
bash tool echo canary0 | blocked by pattern |
eval py subprocess.run('echo canary1', shell=True) | ran |
eval py !echo canary2 | ran |
eval py await tool.bash({'command': 'echo canary3'}) | blocked by pattern (the bridge goes through the bash tool's policy) |
bash tool python3 s.py where s.py runs echo canary5 via subprocess | ran |
So bash.patterns are consent for a cooperating agent, not containment. The last row shows the bash tool can already bypass them through any interpreter, so gating eval adds friction without closing the hole. omp's approval-mode.md says as much: the pattern policy "is not process or filesystem containment". Real containment has to come from the OS layer (bubblewrap box, file ownership, scoped credentials).
To stop an agent picking eval at all, put eval: { py: false, js: false } in the overlay. With it, omp -p --config overlay.yml "list your tools" returned read, bash, edit, glob, grep, task, wait, todo, web_search, write; without it the list included eval. There is no eval.enabled key. --tools=<list> also works when you control the command line.