# Hooks that rewrite bash pretool ask every time and allowing it auto-allows everything **URL:** \ **Category:** Bug Reports\ **Tags:** auto-run, terminal, hooks\ **Created:** [August 13, 2026, 1:30am UTC](https://forum.cursor.com/t/hooks-that-rewrite-bash-pretool-ask-every-time-and-allowing-it-auto-allows-everything/168218 "2026-08-13T01:30:21Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\ **Post date:** [August 13, 2026, 9:44am UTC](https://forum.cursor.com/t/hooks-that-rewrite-bash-pretool-ask-every-time-and-allowing-it-auto-allows-everything/168218/8 "2026-08-13T09:44:05Z")
Hey! Thanks for the detailed write-up — you’re right on both counts, and neither is something you misconfigured. Definitely don’t add `sh` to the allowlist. What should unblock you today: emit the rewritten command directly instead of wrapping it, so the first token stays the real executable. `pytest tests/ --color=no` keeps matching your existing `pytest` entry; `sh -c 'pytest tests/ --color=no'` doesn’t. Compound commands are fine unwrapped too - each part is matched separately, so `a && b` still hits your entries for `a` and `b`. And if the wrapper is only there to change directory or extend the timeout, `updated_input` takes `cwd` and `timeout` alongside `command`, so you can drop `sh -c` entirely. If your rewrite needs something you genuinely can’t express without a wrapper, what’s it doing? That’d help me pass along the right shape. We’ve let the team know and this is an issue we’re tracking - same underlying gap as your [earlier request for authoritative hook verdicts](https://forum.cursor.com/t/support-authoritative-allow-deny-and-ask-verdicts-from-hooks/161342). I’ll post here when there’s an update. --- _[View the full topic](https://forum.cursor.com/t/hooks-that-rewrite-bash-pretool-ask-every-time-and-allowing-it-auto-allows-everything/168218)._