fix(permissions): fail closed when a settings file cannot be read or parsed

[mrhard9090]

Summary

Refs #4282

• A Claude Code settings file that exists but cannot be read or parsed no longer counts as "no rules". load_permission_rules now prints a warning for both cases (the read failure was silent before) and adds a catch-all Ask rule, so every command gets at least Ask, the verdict nothing relaxes. Deny rules from the other settings files still apply first.
• Missing files are skipped as before, and so is a file that is empty or only whitespace.
• The loop moved into load_permission_rules_from(paths) so it can be tested with real files.

What changes in practice: Ask and Default both exit 3 from rtk rewrite, but a delegate that owns approval (RTK_REWRITE_HOST=openclaw, #3909) relaxes Default to an allowed rewrite. With a broken settings.json, a command that file denies was rewritten and allowed there (exit 0); now it exits 3.

Not in this PR: the hooks still call rtk rewrite ... 2>/dev/null, so the warning is not shown in that path, and the Cursor / Gemini / Droid loaders (read_json) are unchanged.

Test plan

• New unit tests: test_valid_settings_file_rules_apply, test_unparseable_settings_file_fails_closed_to_ask, test_unreadable_settings_file_fails_closed_to_ask, test_unreadable_settings_file_keeps_other_files_deny_rules, test_missing_and_empty_settings_files_add_no_rules.
• rtk rewrite "git push origin main" on Linux (WSL Ubuntu 24.04), CLAUDE_CONFIG_DIR with {"permissions":{"deny":["Bash(git push *)"]}} (unreadable = a directory in place of settings.json, since the shell runs as root and chmod 000 does not block it):

settings.json	develop	this PR	develop, openclaw	this PR, openclaw
valid	2	2	2	2
unparseable (trailing comma)	3, warning	3, warning	0, warning	3, warning
unreadable	3, no warning	3, warning	0, no warning	3, warning

• cargo test --bin rtk on Linux: 3787 passed, 8 ignored.
• cargo fmt --all -- --check and cargo clippy --all-targets (clean) on Windows (MSVC).

Written with help from Claude Opus 5.5.

[rtk-wshm-sync-bot]

wshm · Automated triage by AI

📊 Automated PR Analysis

🐛 Type	bug-fix
🟡 Risk	medium

Summary

Fixes rtk's permission rule loader so that a settings.json file which exists but fails to read or parse no longer counts as having no rules. Instead, it now prints a warning and injects a catch-all Ask rule, ensuring commands fail closed (deny/ask) rather than falling through to Default. The loader body was also extracted into a testable load_permission_rules_from(paths) function with accompanying unit tests.

Review Checklist

• Tests present
• Breaking change
• Docs updated

Linked issues: #4282

---

Analyzed automatically by wshm · This is an automated analysis, not a human review.