acp --allow-tool and --deny-tool flags silently ignored: tool restrictions never applied to server

[nightmare0329]

Bug Report

Version: cortex v0.0.7
Command: cortex acp --allow-tool <tool> --deny-tool <tool>

Description

The --allow-tool (whitelist) and --deny-tool (blacklist) flags for cortex acp are advertised in help text to restrict which tools the ACP server makes available to the agent. However, these flags are completely ignored — they are only printed to stderr but never applied to the server configuration.

Steps to Reproduce

$ cortex acp --port 19876 --allow-tool read --deny-tool execute 2>&1 | head -4
Tool whitelist: ["read"]
Tool blacklist: ["execute"]
Starting ACP server on http://127.0.0.1:19876
INFO cortex_engine::acp::server: Starting ACP server on http://127.0.0.1:19876

Expected Behavior

The ACP server should only expose the read tool (whitelist) and block the execute tool (blacklist) from the agent's available tools.

Actual Behavior

The tool lists are printed to stderr but not applied. All tools remain available regardless of --allow-tool/--deny-tool flags.

Screenshot (real binary output)

Root Cause

In src/cortex-cli/src/acp_cmd.rs, the run() function uses eprintln!() to print the tool lists, but never applies them to config:

if !self.allow_tools.is_empty() {
    eprintln!("Tool whitelist: {:?}", self.allow_tools);
    // Note: Tool restrictions are passed via server configuration
    // BUG: config is never updated with allow_tools!
}

if !self.deny_tools.is_empty() {
    eprintln!("Tool blacklist: {:?}", self.deny_tools);
    // Note: Tool restrictions are passed via server configuration
    // BUG: config is never updated with deny_tools!
}

// Server is started with unmodified config:
let server = cortex_engine::acp::AcpServer::new(config);

The config object is built earlier and the tool restriction lists (self.allow_tools, self.deny_tools) are never set on it before passing to AcpServer::new().

File: src/cortex-cli/src/acp_cmd.rs, run() function (~line 88)

[atlas-cortex]

🔁 Validation Summary — Issue #53398

Issue is a duplicate of #53376 (similarity: 0.72)

Duplicate of #53376 — the original issue takes precedence.

Confidence Score: 5/5

• High confidence — this issue substantially overlaps with [BUG] [v0.0.7] cortex acp --allow-tool and --deny-tool flags are printed but never applied to server config #53376.

Validation Checks

Check	Status	Detail
Media Evidence	✅ Pass	Evidence found and accessible
Spam Detection	✅ Pass	Score: 22% — no spam signals
Duplicate Detection	❌ Duplicate	Matches existing issue #53376
Code Verification	✅ Pass	Bug confirmed in source code (confidence: 100%) — The code in acp_cmd.rs prints the allow_tools and deny_tools lists but nev
Edit History	✅ Pass	No suspicious edits
LLM Evaluation	❌ Fail	Issue is a duplicate of #53376 (similarity: 0.72)

Validation Pipeline

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["Issue #53398"] --> B{"Media Check"}
    B -->|"✅ Found"| C{"Spam Check"}
    C -->|"✅ Clean"| D{"Duplicate Check"}
    D -->|"Matches #53376"| Z["🔁 Duplicate"]
    style Z fill:#ffa94d,color:#fff

Loading

Raw Evidence

{
  "media": {
    "hasMedia": true,
    "accessible": true,
    "urls": [
      "https://raw.githubusercontent.com/nightmare0329/cortex-bug-evidence/main/real_acp_allow_deny_bug.png"
    ],
    "evidence": [
      "Found 1 media URL(s) via GitHub rendered HTML",
      "1 URL(s) accessible"
    ]
  },
  "spam": {
    "overallScore": 0.21597938144329898,
    "details": "template=0.33 (7 recent issues compared); burst=1.00 (8 issues in 2h window); parity=0.00; overall=0.43 (threshold=0.7); llm_spam=0.00 (The issue provides a highly specific title and clear steps to reproduce the bug using the CLI. Expected and actual behaviors are explicitly defined, and the reporter has gone as far as identifying the exact root cause in the source code (`src/cortex-cli/src/acp_cmd.rs`). While the automated extraction listed no media URLs, a direct link to a screenshot is present in the markdown body. There are no indicators of spam or template farming, and no duplicate issues were flagged. The report is thorough and actionable.)"
  },
  "duplicate": {
    "isDuplicate": true,
    "originalIssue": 53376,
    "similarity": 0.7208210776176359,
    "topSimilar": [
      {
        "issueNumber": 53376,
        "title": "[BUG] [v0.0.7] `cortex acp --allow-tool` and `--deny-tool` flags are printed but never applied to server config",
        "similarity": 0.7208210776176359
      },
      {
        "issueNumber": 52524,
        "title": "[BUG] [v0.0.7] `cortex acp --allow-tool` / `--deny-tool` are parsed but never applied to the ACP server configuration",
        "similarity": 0.6791412348076562
      },
      {
        "issueNumber": 51767,
        "title": "[BUG] [v0.0.7] --allow-tool / --deny-tool flags are not enforced (stderr-only behavior)",
        "similarity": 0.6453546520282754
      },
      {
        "issueNumber": 51294,
        "title": "[BUG] [v0.0.7] cortex acp validates --agent and parses --allow-tool/--deny-tool but does not apply them to Config or the ACP server",
        "similarity": 0.6237632504513608
      },
      {
        "issueNumber": 52892,
        "title": "[CLI][v0.0.7] `cortex acp`: same tool can appear in `--allow-tool` and `--deny-tool` with no warning or error",
        "similarity": 0.548783381040882
      }
    ]
  },
  "editHistory": {
    "fraudScore": 0,
    "editCount": 0,
    "details": "No edits detected"
  },
  "codeVerification": {
    "plausible": true,
    "confidence": 1,
    "reasoning": "The code in `acp_cmd.rs` prints the `allow_tools` and `deny_tools` lists but never applies them to the `config` object passed to `AcpServer::new()`. Furthermore, `cortex_engine::Config` does not contain fields to store these tool restrictions, confirming they are completely ignored.",
    "codeEvidence": "src/cortex-cli/src/acp_cmd.rs lines 89-97 show that `self.allow_tools` and `self.deny_tools` are printed but never added to `config`. `cortex_engine::Config` doesn't even have fields for them.",
    "screenshotValid": true,
    "screenshotReasoning": "The screenshot shows the actual CLI output where the tool whitelist and blacklist are printed to stderr, but the server starts without applying them, matching the described bug."
  }
}

_{Validated by Atlas • 2026-04-16}