Denied bare gh should route to coily ops gh in the recovery message #5
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally filed by @coilysiren on 2026-05-21T13:23:35Z - https://github.com/coilysiren/agent-guard/issues/27
Problem -
gh issue create(and likely otherghwrite subcommands) gets denied by the lockdown with the generic harness message "Permission to use Bash with command X has been denied." The denial does not name thecoily ops ghwrapper that is the correct route. An agent hitting this dead-ends: it retries variations, hands the command back to Kai, or gives up. In this session it took five denials and a hint from Kai before the agent foundcoily ops gh.Expected - When the lockdown denies a
ghinvocation, the recovery message should name the wrapper, the same way other coily-routed denials do. Something like: "ghis denied bare. Runcoily ops gh <args>instead."Why this matters - AGENTS.md "Mobile-First Dev and Ops": opaque errors are design smells, recovery messages should name the command to dictate next. A denial that does not route is the worst case - the agent cannot self-correct and Kai has to intervene.
Where to look -
coilysiren/agent-guard, thecoilyRoutestable incmd/agent-guard/hook.go. Eitherghis missing a route entry, or the route exists but its recovery hint is not surfacing through to the harness denial message. Confirm which, then fix so every deniedghform emits thecoily ops ghhint.Origin: surfaced filing GitHub issues during a design session -
gh issue createdenied repeatedly with no routing hint.