Henner M. Kruse
15 lines
1.4 KiB
JSON
15 lines
1.4 KiB
JSON
{
|
|
"_comment": "Reference only — setup.sh generates and writes these exact rules itself, so this file is no longer read during setup. Kept here for auditing/documentation: this is what /git-manager:setup will add to your permissions.allow, with <SKILL_DIR> substituted for the real, symlink-resolved skills/git-manager path. Exactly one Bash rule — the wrapper script itself — never a generic Bash(git:*) or anything targeting cd. The wrapper script enforces its own subcommand allowlist (status, log, diff, show, fetch, remote, branch, checkout, add, commit, push, pull) and resolves repo paths only from named entries in ~/.agent-skills/git-manager/config.json, never from the current working directory or an arbitrary caller-supplied path.",
|
|
"permissions": {
|
|
"allow": [
|
|
"Bash(<SKILL_DIR>/scripts/git_cmd.sh:*)",
|
|
"Read(~/.agent-skills/git-manager/config.json)"
|
|
]
|
|
},
|
|
"_deliberately_not_whitelisted": [
|
|
"No generic Bash(git:*) — that would allow any git subcommand, including destructive ones like reset --hard, clean -fdx, or filter-branch, which are not on the wrapper's allowlist for a reason.",
|
|
"No Bash(cd:*) — the wrapper's --repo flag and its default-to-$PWD behavior remove any legitimate need for cd, and cd:* is a known vector for whitelist bypass via chaining (e.g. cd X && anything).",
|
|
"No write access to the config file — registering a new named repo stays a confirmed action every time."
|
|
]
|
|
}
|