Name the coily wrapper in the deny message for pass-through tools #47

New issue

Closed

opened 2026-06-03 00:39:12 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-06-03 00:39:12 +00:00

Owner

Friction

An agent that reaches for a bare tool coily wraps (kubectl, aws, gh, flyctl, gcloud, mcporter) hits the cli-guard deny and often gives up, never learning the allowed path exists. Concrete case today: an agent needed cluster access, ran bare kubectl, got denied, and concluded kai-server was unreachable - when coily ops kubectl was available the whole time and resolved it instantly.

Options considered

Thin skill per wrapped command - rejected. Dozens of 1:1 mirror skills, always-on context cost, fights skill-authoring discipline, and skills surface on description-match, NOT at the moment a bare command is denied - so they wouldn't fire when it matters.
Annotation on the deny (recommended) - cli-guard already intercepts the call and knows which binary was denied. Add a tool->wrapper redirect map so the denial message says e.g. "blocked: route through coily ops kubectl". Highest signal (the denial is the teachable moment), lowest maintenance, zero context cost until needed. Covers exactly the pass-through set coily already wraps.
Both, narrowly - the redirect map is the mechanism; a SINGLE existing pointer (coily-meta) can list the wrapped-tool set for agents planning ahead. Not one skill per verb.

Proposed

Add the bare-tool -> coily ops <tool> redirect map to the cli-guard pre-tool-use deny message for the pass-through set (aws, gh, kubectl, flyctl, gcloud, mcporter). Ships from coily/cli-guard.

## Friction An agent that reaches for a bare tool coily wraps (`kubectl`, `aws`, `gh`, `flyctl`, `gcloud`, `mcporter`) hits the cli-guard deny and often gives up, never learning the allowed path exists. Concrete case today: an agent needed cluster access, ran bare `kubectl`, got denied, and concluded kai-server was unreachable - when `coily ops kubectl` was available the whole time and resolved it instantly. ## Options considered - **Thin skill per wrapped command** - rejected. Dozens of 1:1 mirror skills, always-on context cost, fights skill-authoring discipline, and skills surface on description-match, NOT at the moment a bare command is denied - so they wouldn't fire when it matters. - **Annotation on the deny (recommended)** - cli-guard already intercepts the call and knows which binary was denied. Add a tool->wrapper redirect map so the denial message says e.g. "blocked: route through `coily ops kubectl`". Highest signal (the denial is the teachable moment), lowest maintenance, zero context cost until needed. Covers exactly the pass-through set coily already wraps. - **Both, narrowly** - the redirect map is the mechanism; a SINGLE existing pointer (coily-meta) can list the wrapped-tool set for agents planning ahead. Not one skill per verb. ## Proposed Add the bare-tool -> `coily ops <tool>` redirect map to the cli-guard pre-tool-use deny message for the pass-through set (aws, gh, kubectl, flyctl, gcloud, mcporter). Ships from coily/cli-guard.

coilysiren added the

label

2026-06-04 08:16:52 +00:00

coilysiren added this to the sunday-sprint milestone

2026-06-05 03:41:18 +00:00

coilysiren added the

sunday-sprint

label

2026-06-05 03:41:18 +00:00

coilysiren commented

2026-06-17 08:23:26 +00:00

Author

Owner

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: burndown-2026-06.

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: `burndown-2026-06`.

coilysiren

2026-06-17 08:23:27 +00:00