Files that are really your Claude Code config get their own handling

What

• File reads: a new denial reason explains when a read is withheld because the file is linked from your Claude Code configuration, instead of falling into a generic "sensitive" bucket.
• The sandbox readability check gained a host_config classification (via a new hostConfig parameter) alongside its existing read_denied/sensitive/sensitive_tracked outcomes, and can report rules_unreadable when the host config itself can't be read.
• Repo-sync/diff logic (used for things like merges and worktree checks) now detects files that are actually the machine's own Claude Code configuration linked in under another name, and withholds them with two new reasons: withheld_host_config (configuration linked under another name) and withheld_config_unexamined (the configuration couldn't be fully examined).
• File-scan summaries gained a skipped_host_config counter, alongside existing counters like skipped_sensitive_tracked and skipped_read_denied.
• Write protection recognizes the same two cases for writes: the target is the machine's own configuration under another name, or the configuration couldn't be fully examined (unreadable link/directory, or too many entries).
• File-refusal classification for restricted reads gained its own host_config reason, previously lumped in with read_denied/not_regular_file, and it's now counted among refusal reasons treated as sensitive/blocked.

Why

This stops Claude Code from treating your own configuration files as generic unreadable or sensitive files when they're reached through a symlink or alias, giving clearer, more specific explanations across reads, writes, and file scans.