lockdown v2.45.0 render loosens .claude/settings.json (drops shell/interpreter denylist, widens git allow to Bash(git:*)) #155

New issue

Closed

opened 2026-05-29 04:08:24 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-05-29 04:08:24 +00:00

Owner

Summary

The coily v2.45.0 lockdown render of .claude/settings.json loosens the
security posture versus the intended hardened baseline. It drops the entire
shell/interpreter denylist and widens the git allow rule from specific
read-only subcommands to a blanket Bash(git:*).

Observed render diff (hardened baseline -> v2.45.0 render)

permissions.allow:

removes the 10 read-only git entries (git blame:*, git branch:*,
git config --get:*, git diff:*, git log:*, git ls-files:*,
git remote:*, git rev-parse:*, git show:*, git status:*)
adds blanket Bash(git:*) -- this re-enables exec-capable git flags
(-c core.sshCommand=, --upload-pack=, --exec=) and arbitrary
subcommands

permissions.deny:

removes the shell/interpreter denylist: bash, sh, zsh, dash, ksh,
fish, python/python3, node, deno, ruby, perl,
powershell/pwsh (+ .exe), cmd/cscript/wscript/mshta/rundll32/
regsvr32 (+ .exe), osascript, env, exec, xargs, the
echo*$* / printf*$* shell-substitution guards, and PowerShell(*)
also drops terraform, helm, rsync, sshfs, tox, nox, tflint,
tfsec, go run

Impact / why it matters

This is a real loosening of the allow/deny posture, not a cosmetic render
churn. It recurs every lockdown cycle on a v2.45.0 host, so a hardened repo
silently drifts back to loose on the next coily setup / coily lockdown.

Observed concretely in coilysiren/agentic-os-kai:

the v2.45.0 render landed on the forgejo remote as commit 224e5b2
(lockdown: sync to coily v2.45.0 [skip ci])
origin/GitHub had already rejected it (e99cd63 revert: restore hardened .claude/settings.json allow/deny lists)
the same render keeps reappearing as a dirty working-tree change
caused a forgejo<->origin divergence; reconciled manually, but it will
drift again until the render is fixed

The repo sits behind the coily lockdown + agent-guard PreToolUse layer, which
backstops the deny removals, but the widened Bash(git:*) allow is not
backstopped the same way.

Asks

Decide the intended baseline: should v2.45.0 ship the hardened denylist +
narrowed git allow, or was the loosening intentional (posture consolidated
into agent-guard)? If intentional, document it so the hardened repos stop
fighting the render.
If unintentional: fix the render so it emits the hardened allow/deny lists
(or at least never widens git blame:*... to git:*).
Make the render idempotent against the hardened baseline so it stops
producing recurring dirty-tree drift.

## Summary The coily v2.45.0 lockdown render of `.claude/settings.json` loosens the security posture versus the intended hardened baseline. It drops the entire shell/interpreter denylist and widens the git allow rule from specific read-only subcommands to a blanket `Bash(git:*)`. ## Observed render diff (hardened baseline -> v2.45.0 render) `permissions.allow`: - removes the 10 read-only git entries (`git blame:*`, `git branch:*`, `git config --get:*`, `git diff:*`, `git log:*`, `git ls-files:*`, `git remote:*`, `git rev-parse:*`, `git show:*`, `git status:*`) - adds blanket `Bash(git:*)` -- this re-enables exec-capable git flags (`-c core.sshCommand=`, `--upload-pack=`, `--exec=`) and arbitrary subcommands `permissions.deny`: - removes the shell/interpreter denylist: `bash`, `sh`, `zsh`, `dash`, `ksh`, `fish`, `python`/`python3`, `node`, `deno`, `ruby`, `perl`, `powershell`/`pwsh` (+ `.exe`), `cmd`/`cscript`/`wscript`/`mshta`/`rundll32`/ `regsvr32` (+ `.exe`), `osascript`, `env`, `exec`, `xargs`, the `echo*$*` / `printf*$*` shell-substitution guards, and `PowerShell(*)` - also drops `terraform`, `helm`, `rsync`, `sshfs`, `tox`, `nox`, `tflint`, `tfsec`, `go run` ## Impact / why it matters This is a real loosening of the allow/deny posture, not a cosmetic render churn. It recurs every lockdown cycle on a v2.45.0 host, so a hardened repo silently drifts back to loose on the next `coily setup` / `coily lockdown`. Observed concretely in `coilysiren/agentic-os-kai`: - the v2.45.0 render landed on the forgejo remote as commit `224e5b2` (`lockdown: sync to coily v2.45.0 [skip ci]`) - origin/GitHub had already rejected it (`e99cd63 revert: restore hardened .claude/settings.json allow/deny lists`) - the same render keeps reappearing as a dirty working-tree change - caused a forgejo<->origin divergence; reconciled manually, but it will drift again until the render is fixed The repo sits behind the coily lockdown + agent-guard PreToolUse layer, which backstops the *deny* removals, but the widened `Bash(git:*)` *allow* is not backstopped the same way. ## Asks 1. Decide the intended baseline: should v2.45.0 ship the hardened denylist + narrowed git allow, or was the loosening intentional (posture consolidated into agent-guard)? If intentional, document it so the hardened repos stop fighting the render. 2. If unintentional: fix the render so it emits the hardened allow/deny lists (or at least never widens `git blame:*`... to `git:*`). 3. Make the render idempotent against the hardened baseline so it stops producing recurring dirty-tree drift.

coilysiren commented

2026-05-30 05:43:13 +00:00

Author

Owner

Merged into #115 in the 2026-05-29 backlog burn-down. Same lockdown git catch-all / dropped denylist issue Reopen if it should stand alone.

coilysiren closed this issue

2026-05-30 05:43:13 +00:00

coilysiren added the

label

2026-05-31 01:52:36 +00:00

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

coilyco-bridge/coily#155

No description provided.

Rows
Columns