fix: deny bash tool for prometheus agent (#2273)

[guazi04]

Summary

Closes #2273

Problem: Prometheus's prometheus-md-only hook only blocks Write and Edit tools, but bash commands (cp, rm, python3 -c, etc.) can bypass file restrictions entirely.

Fix: Added bash: "deny" and interactive_bash: "deny" to Prometheus's tool permissions in tool-config-handler.ts.

Changes

• src/plugin-handlers/tool-config-handler.ts — Added bash and interactive_bash deny rules to Prometheus agent permissions
• src/plugin-handlers/tool-config-handler.test.ts — Added 4 new tests verifying the deny behavior for both tools

Testing

• 4 new unit tests covering:
  • bash tool denied for Prometheus
  • interactive_bash tool denied for Prometheus
  • Verification that other agents (Sisyphus) are NOT affected by the deny rules
  • Verification that non-denied tools still work for Prometheus
• All existing tests pass
• TypeScript typecheck passes
• Build passes

---

Summary by cubic

Deny bash and interactive_bash tools for the Prometheus agent to enforce prometheus-md-only and stop shell command bypasses (cp, rm, python3 -c). Other agents are unaffected; non-denied tools still work for Prometheus.

^{Written for commit 403efd7. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Auto-approved: The changes are narrowly scoped to the Prometheus agent and include comprehensive tests verifying that other agents are unaffected, ensuring no regressions.}

[acamq]

Thank you for the detailed investigation and well-structured PR. However, this approach is not the right fix for the issue.

Context

After reviewing the original issue (#2273) and the design intent:

1. The issue is valid — Prometheus was able to bypass the prometheus-md-only hook by using bash commands (cp, rm, python3 -c) instead of Write/Edit tools.

2. Bash access is intentional — Prometheus was given bash tools deliberately. As the repo owner confirmed, "Prometheus deserves to have it to understand current situation by executing commands."

Why This PR Is Incorrect

Denying bash tools entirely would break Prometheus's intended functionality. Prometheus needs bash to:

• Inspect the codebase state (ls, cat, find)
• Understand the current situation through commands
• Gather context for planning

The prometheus-md-only hook's purpose is to prevent file modifications, not to make Prometheus completely read-only. The issue is that the hook (at src/hooks/prometheus-md-only/hook.ts) only blocks Write and Edit tools (BLOCKED_TOOLS = ["Write", "Edit", "write", "edit"]), while bash commands can still modify files.

Recommended Approach

The fix should be in the prometheus-md-only hook itself, not in tool permissions:

1. Option A: Enhance the hook to also intercept bash commands that could modify files (e.g., block cp, mv, rm, python3 -c that writes files, etc.)

2. Option B: Update the hook's error message and agent instructions to clarify the distinction — bash is allowed for inspection but Prometheus should not use bash to modify files. Then strengthen the agent's system prompt to not work around the restriction.

Option A is more robust but more complex. Option B relies on agent behavior but is simpler.

Suggestion

The prometheus-md-only hook in src/hooks/prometheus-md-only/hook.ts is where the fix belongs, not in tool-config-handler.ts. Thanks for the contribution and for surfacing the issue. Feel free to continue discussion on #2273 .

[guazi04]

@acamq Thanks for the detailed feedback on this PR. I went ahead and implemented Option A in #2403 — a bash command analyzer with allowlisted read-only commands and a custom tokenizer.

After two rounds of automated review (cubic) and significant iteration, I've come to believe Option A is fundamentally untenable. Here's why:

The tokenizer approach has a ceiling

The current implementation is 424 lines of hand-written bash tokenizer + command policy. After fixing the first round of issues, cubic's second review found 8 more bypasses (4× P0 security):

• Quoted flags bypass blocklists ("-exec" ≠ -exec after tokenization)
• No-space redirections (echo"data">/etc/passwd) invisible to whitespace-based tokenizer
• Positional output arguments (xxd infile outfile, uniq in out) can't be caught by flag checking
• rg --pre enables arbitrary command execution (CVE-2021-3013)
• hasSubshells() missing double-quote state tracking
• File descriptor redirects (3>/etc/shadow) not detected
• And more...

Each fix introduces new edge cases. Bash syntax is effectively Turing-complete — a regex/tokenizer-based policy will always have gaps. This isn't a matter of writing better code; it's a fundamental limitation of the approach.

Proposal: Option C — Replace bash with existing read-only tools

Prometheus needs bash for one thing: inspecting the codebase. But we already have purpose-built read-only tools that do this better:

Bash command	Existing tool	Advantage
cat, head, tail	Read (with offset/limit)	Line numbers, pagination
grep, rg	Grep	Regex, output modes, file filtering
find, ls	Glob	Pattern matching, sorted by mtime
—	lsp_goto_definition, lsp_find_references, lsp_symbols	Semantic code understanding

This is already proven. Oracle, Librarian, and Explore are all read-only agents that operate without bash — and they work great. Prometheus would follow the same pattern.

The implementation would be minimal: deny bash/interactive_bash in tool permissions (similar to what this PR originally proposed), while ensuring all read-only tools are available. Much less code, zero attack surface, and no ongoing maintenance burden from chasing bash parser edge cases.

I'd like to hear your thoughts before continuing work on #2403. If Option C is acceptable, I can update that PR accordingly.