dgf1988/codewhale
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

fix(hooks): require workspace trust for project hooks

Browse Source 
Gate .codewhale/hooks.toml behind user-owned workspace trust, mirroring the project-local MCP trust boundary while preserving shell-command hook semantics.

Harvested from PR #3140.

Co-authored-by: Hmbown <101357273+Hmbown@users.noreply.github.com>

Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
This commit is contained in:
Hunter B
2026-06-12 02:38:56 -07:00
parent 119285f056
commit d50dfd4827
5 changed files with 118 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/CONFIGURATION.md
+10 -4
View File
@@ -691,10 +691,16 @@ metacharacters in the pattern are matched literally.
Repositories can ship policy in `<workspace>/.codewhale/hooks.toml`,
using the same shape as the `[hooks]` table (top-level fields plus
`[[hooks]]` entries). Project hooks are appended after global hooks
from `config.toml`, so they run last and, for `updatedInput`, win
ties. A malformed project file logs a warning and startup falls back
to global hooks only.
`[[hooks]]` entries). Project hooks are executable shell
configuration, so CodeWhale only loads them after the workspace has
been trusted in user-owned config through the trust prompt or a
`[projects."<workspace>"] trust_level = "trusted"` entry. Session
`/trust on` mode does not enable repo-supplied hooks by itself, and
repo-local legacy markers such as `.deepseek/trusted` do not enable
project hooks. Once trusted, project hooks are appended after global
hooks from `config.toml`, so they run last and, for `updatedInput`,
win ties. A malformed trusted project file logs a warning and startup
falls back to global hooks only.
```toml
# .codewhale/hooks.toml