Repository navigation
fix(s03,s04,s20): resolve Gate2 safe_path conflict — permission dead on write/edit - #484
Merged
Merged
Conversation
added 3 commits
July 28, 2026 17:47
…/edit Gate 2 (PERMISSION_RULES) and safe_path() used the same path check: (WORKDIR / path).resolve().is_relative_to(WORKDIR) But gave contradictory semantics: - Gate 2: soft rule, user-approvable - safe_path: hard ValueError, unbypassable Result: user approval at Gate 2 was never effective; 1. Remove hard error from safe_path, keep only str->Path 2. Inline path resolution in run_read/run_write/run_edit 3. Add read_file to PERMISSION_RULES coverage Closes #482
s04_hooks: permission_hook checks path + asks user, but safe_path still raised hard ValueError — user approval was ineffective, same root cause as s03 (#482). s20_comprehensive: permission_hook used safe_path directly inside try/except, silently denying all writes outside workspace without ever asking the user. Now uses is_relative_to check + user prompt. Both files also add read_file to the permission coverage. s05-s08 intentionally NOT changed: their permission_hook does not check paths at all — safe_path is their only path-safety defense.
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
learn-claude-code | c959829 | Jul 28 2026, 11:39 AM |
Bill-Billion
added a commit
that referenced
this pull request
Jul 28, 2026
…lict fix(s03,s04,s20): resolve Gate2 safe_path conflict — permission dead on write/edit Co-authored-by: Viper <41693046+ClearVIper3@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Supersedes #483. Credits to @ClearVIper3 for the initial s03 fix, extended here to s04 and s20.
Problem
In s03, Gate 2 (PERMISSION_RULES) and safe_path() used the same path check but with contradictory semantics:
Result: user approval at Gate 2 was never effective — safe_path always blocked execution first.
The same bug exists in s04_hooks and s20_comprehensive.
Fix
Files changed
s03_permission/code.py: Delete safe_path, inline paths, expand Gate 2 to read_file
s03_permission/README..md (3): Update Gate 2 table + code snippet
s04_hooks/code.py: Same fix: delete safe_path, inline paths, expand permission_hook
s04_hooks/README..md (3): Update permission_hook snippet
s20_comprehensive/code.py: Same fix + replace safe_path-based try/except with user prompt
s20_comprehensive/README.*.md: (no snippet to update)
Intentionally NOT changed
s05~s08: their permission_hook only checks bash deny list — path checking is absent from the permission layer. safe_path is their only path defense and must stay.
Closes #482