Skip to content

Per-Project Bash Command Allowlist System #80

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
leonvanzyl merged 5 commits into from
Jan 23, 2026
Merged

Per-Project Bash Command Allowlist System #80

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
a9a0fcd
feat: add per-project bash command allowlist system
ipodishima Jan 22, 2026
d1dac13
security: prevent bare wildcard '*' from matching all commands
ipodishima Jan 22, 2026
f1b48be
feat: increase command limit to 100 and add optimization guide
ipodishima Jan 22, 2026
996ac00
fix: improve path matching and org config validation
ipodishima Jan 22, 2026
edff398
test: add safe environment variable handling in integration tests
ipodishima Jan 22, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
82 changes: 81 additions & 1 deletion CLAUDE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -169,19 +169,99 @@ Projects can be stored in any directory (registered in `~/.autocoder/registry.db
- `prompts/coding_prompt.md` - Continuation session prompt
- `features.db` - SQLite database with feature test cases
- `.agent.lock` - Lock file to prevent multiple agent instances
- `.autocoder/allowed_commands.yaml` - Project-specific bash command allowlist (optional)

### Security Model

Defense-in-depth approach configured in `client.py`:
1. OS-level sandbox for bash commands
2. Filesystem restricted to project directory only
3. Bash commands validated against `ALLOWED_COMMANDS` in `security.py`
3. Bash commands validated using hierarchical allowlist system

#### Per-Project Allowed Commands

The agent's bash command access is controlled through a hierarchical configuration system:

**Command Hierarchy (highest to lowest priority):**
1. **Hardcoded Blocklist** (`security.py`) - NEVER allowed (dd, sudo, shutdown, etc.)
2. **Org Blocklist** (`~/.autocoder/config.yaml`) - Cannot be overridden by projects
3. **Org Allowlist** (`~/.autocoder/config.yaml`) - Available to all projects
4. **Global Allowlist** (`security.py`) - Default commands (npm, git, curl, etc.)
5. **Project Allowlist** (`.autocoder/allowed_commands.yaml`) - Project-specific commands

**Project Configuration:**

Each project can define custom allowed commands in `.autocoder/allowed_commands.yaml`:

```yaml
version: 1
commands:
# Exact command names
- name: swift
description: Swift compiler

# Prefix wildcards (matches swiftc, swiftlint, swiftformat)
- name: swift*
description: All Swift development tools

# Local project scripts
- name: ./scripts/build.sh
description: Project build script
```

**Organization Configuration:**

System administrators can set org-wide policies in `~/.autocoder/config.yaml`:

```yaml
version: 1

# Commands available to ALL projects
allowed_commands:
- name: jq
description: JSON processor

# Commands blocked across ALL projects (cannot be overridden)
blocked_commands:
- aws # Prevent accidental cloud operations
- kubectl # Block production deployments
```

**Pattern Matching:**
- Exact: `swift` matches only `swift`
- Wildcard: `swift*` matches `swift`, `swiftc`, `swiftlint`, etc.
- Scripts: `./scripts/build.sh` matches the script by name from any directory

**Limits:**
- Maximum 100 commands per project config
- Blocklisted commands (sudo, dd, shutdown, etc.) can NEVER be allowed
- Org-level blocked commands cannot be overridden by project configs

**Testing:**
```bash
# Unit tests (136 tests - fast)
python test_security.py

# Integration tests (9 tests - uses real hooks)
python test_security_integration.py
```
Comment on lines +241 to +247
Copy link

@coderabbitai coderabbitai bot Jan 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Avoid hard‑coding test counts in docs.
The counts can drift quickly; consider removing the numbers or ensuring they’re updated alongside test changes.

📝 Suggested doc adjustment 
-# Unit tests (136 tests - fast)
+# Unit tests (fast)
 ...
-# Integration tests (9 tests - uses real hooks)
+# Integration tests (uses real hooks)
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
```bash
# Unit tests (136 tests - fast)
python test_security.py
# Integration tests (9 tests - uses real hooks)
python test_security_integration.py
```
# Unit tests (fast)
python test_security.py
# Integration tests (uses real hooks)
python test_security_integration.py
🤖 Prompt for AI Agents 
In `@CLAUDE.md` around lines 241 - 247, Remove the hard-coded test counts next to
the test commands—specifically the "(136 tests - fast)" and "(9 tests - uses
real hooks)" annotations that follow the lines containing "python
test_security.py" and "python test_security_integration.py"; either delete the
counts entirely or replace them with a stable descriptor like "(unit tests)" and
"(integration tests - uses real hooks)" or a note that counts may change and to
run the commands to see current results.


**Files:**
- `security.py` - Command validation logic and hardcoded blocklist
- `test_security.py` - Unit tests for security system (136 tests)
- `test_security_integration.py` - Integration tests with real hooks (9 tests)
- `TEST_SECURITY.md` - Quick testing reference guide
- `examples/project_allowed_commands.yaml` - Project config example (all commented by default)
- `examples/org_config.yaml` - Org config example (all commented by default)
- `examples/README.md` - Comprehensive guide with use cases, testing, and troubleshooting
- `PHASE3_SPEC.md` - Specification for mid-session approval feature (future enhancement)

## Claude Code Integration

- `.claude/commands/create-spec.md` - `/create-spec` slash command for interactive spec creation
- `.claude/skills/frontend-design/SKILL.md` - Skill for distinctive UI design
- `.claude/templates/` - Prompt templates copied to new projects
- `examples/` - Configuration examples and documentation for security settings

## Key Patterns

Expand Down
Loading