Feature Request: Allow custom commands to specify allowed file paths in markdown frontmatter

Summary

Add support for custom commands (slash commands) to specify allowed file paths in markdown frontmatter, eliminating the need for repeated permission prompts when accessing files outside the project directory. This issue text was created with Claude Code assistance.

Motivation

When using custom commands that need to access shared instruction files (like ~/.claude/instructions), users currently face repeated permission prompts every time the command runs. This creates friction in workflows that rely on global configuration files or shared resources.

Current workflow:

1. Execute /MY-RULE custom command
2. Command attempts to read ~/.claude/instructions
3. Claude Code prompts: "Allow reading files in ~/.claude/instructions?"
4. User must manually approve each time
5. Command proceeds with file access

This repetitive permission flow becomes cumbersome when:

• Custom commands are used frequently throughout development
• Multiple projects share the same global instruction files
• Commands need to access well-known, trusted directories like ~/.claude/

Proposed Solution

Allow custom commands to declare trusted file paths in markdown
frontmatter:

---
allowed-paths:
- ~/.claude/instructions
- ~/shared-resources
- /usr/local/shared-config
---

## Custom Command Implementation
<!-- command logic here -->

Alternative Syntax Options

Option 1: YAML frontmatter (preferred)

---
allowed-paths:
- ~/.claude/instructions
- ~/shared-resources
permissions:
read:
- ~/.claude/instructions
---

Option 2: Comment-based metadata

<!-- allowed-tools: READ -->
<!-- allowed-paths: ~/.claude/instructions, ~/shared-resources -->

Custom Command

Security Considerations

• Paths should be explicitly listed (no wildcards initially)
• Consider restricting to specific "safe" directories (e.g., ~/.claude/, ~/.config/)
• Maintain audit trail of pre-approved paths
• Allow users to revoke permissions via settings

Benefits

1. Improved UX: Eliminates repetitive permission prompts
2. Better workflows: Enables seamless integration with global configurations
3. Consistency: Aligns with how other tools handle trusted directories
4. Maintainability: Clear declaration of external dependencies

Current Workarounds

Users currently work around this by:

• Creating symbolic links: ln -s ~/.claude/instructions .claude-instructions
• Copying files into project directories
• Setting environment variables (limited effectiveness)

These workarounds are functional but add complexity and maintenance overhead.

Use Cases

• Global instruction files: ~/.claude/instructions for consistent AI behavior
• Shared templates: Team-wide configuration files
• Tool configurations: Access to ~/.config/ directories
• Documentation: Shared knowledge bases outside project scope

Implementation Notes

This feature would complement the existing security model while providing convenience for trusted, user-specified paths. The explicit declaration in frontmatter makes the external dependencies visible and auditable.