Remote auto-approve safe tools uses inconsistent tool names

[MicroMilo]

Summary

Remote autoApproveSafeTools promises to auto-approve safe tools such as file reads and browser operations, but the remote validator compares a display/tool name against a case-sensitive safelist that uses different names. As a result, minimal safe-tool inputs such as read and navigate_page are not auto-approved, while Task is auto-approved even though the UI copy does not describe delegation/subagent tools as safe.

Minimal Reproduction

1. Enable remote control with autoApproveSafeTools=true.
2. Send these tool names through the same remote auto-approve check used by remote-manager.ts:
   • read
   • navigate_page
   • Task

Current result:

• read does not match the safelist entry Read.
• navigate_page does not match the safelist entry mcp__Chrome__navigate_page.
• Task matches the safelist and is auto-approved.

Evidence

• src/renderer/components/remote/AdvancedConfigStep.tsx:63-83 renders the autoApproveSafeTools toggle.
• src/renderer/i18n/locales/en.json:840-841 describes the feature as auto-approving safe tools such as file reads and browser operations.
• src/main/remote/remote-manager.ts:618-655 performs auto-approval with safeTools.includes(toolName).
• src/main/remote/remote-manager.ts:621-648 includes Read, Chrome MCP canonical-looking names such as mcp__Chrome__navigate_page, and Task in the safelist.
• src/main/claude/agent-runner.ts:979-982 passes displayName to requestPermission(...), not the canonical toolName.
• src/main/claude/agent-runner.ts:1021-1042 can serialize MCP tools to names such as navigate_page.
• src/main/config/permission-rules-store.ts:18-28 and src/renderer/store/index.ts:207-214 use lowercase local default tool names such as read, glob, grep, and ls.

Actual Behavior

The remote auto-approve path is name-sensitive and receives names that do not match the safelist. Safe file/browser operations are not reliably auto-approved. Task is auto-approved although the user-facing description does not include delegation/subagent capability in the safe-tool boundary.

Expected Behavior

Remote auto-approval should use one canonical tool-name contract. User-visible display names can be used in UI messages, but authorization should not depend on display names or case variants.

The Task entry should either be removed from the default safe list or explicitly documented in the UI as an auto-approved capability.

Existing Issue / PR Coverage

Checked open and closed issues/PRs with:

• autoApproveSafeTools safeTools remote permission Task
• requestPermission displayName remote safe tools

No direct coverage was found.

Related but not covering this bug:

• Local-chat tools execute without approval: PermissionDialog and settings.permissionRules are not wired to the pi-coding-agent tool path #164 covers local chat tools executing without approval. It does not cover remote safe-tool name drift.
• feat(permissions): gate local-agent tool calls through PermissionDialogMike/feat/permissions #165 wires local-agent tool calls through the permission dialog. It touches adjacent permission code but does not fix remote-manager.ts safelist matching or the Task safe-tool boundary.

Proposed Fix

• Carry both canonical tool name and display name in permission request payloads.
• Base remote auto-approval on canonical names only.
• Keep display names only for user-facing feedback.
• Add a normalization helper for MCP names, casing, originalName, and display names.
• Re-evaluate whether Task should be in the default safe list.

Suggested Tests

• With autoApproveSafeTools=true, read, glob, grep, and ls are auto-approved through canonical matching.
• Chrome MCP browser tools are auto-approved regardless of display-name serialization.
• Task behavior is explicitly tested: either not auto-approved, or documented and intentionally auto-approved.

[github-actions]

Thank you for this thorough analysis, @MicroMilo! You've identified a real inconsistency in how remote auto-approval matches tool names. I've verified the code paths you cited in the codebase and can confirm the issue:

• src/main/remote/remote-manager.ts:618-655 uses safeTools.includes(toolName) where safeTools contains display-name-style entries like Read and mcp__Chrome__navigate_page, but the actual toolName passed via requestPermission comes from agent-runner.ts:979-982 which uses displayName, and from agent-runner.ts:1021-1042 which can serialize MCP tools to bare names like navigate_page.
• Meanwhile, the local permission system (permission-rules-store.ts:18-28) uses lowercase canonical names like read, glob, grep, ls.
• The Task tool being auto-approved is also a concern since the UI description (autoApproveSafeTools) only mentions "file reads and browser operations" — not delegation/subagent tools.

Your proposed fix — carrying both canonical tool name and display name, basing auto-approval on canonical names only, and normalizing MCP names — is exactly the right approach. I'd also suggest:

1. Add a normalization helper that maps display names to canonical names (e.g., via a lookup table or by lowercasing and removing mcp__CHROME__ prefixes).
2. Update safeTools in remote-manager.ts to use only canonical names (e.g., ['read', 'glob', 'grep', 'ls', 'navigate_page', ...]).
3. Re‑evaluate Task — consider removing it from the default safe list unless delegation is explicitly documented as a safe capability.
4. Add unit tests for the auto-approval logic covering both remote and local tool-name scenarios.

Would you like to contribute a PR with these changes? Happy to guide you through the codebase structure. Let me know if you need any clarification on the normalization approach.

---

Open Cowork Bot

[MicroMilo]

I opened PR #260 to address this.

The fix normalizes remote tool names before checking autoApproveSafeTools, so display names such as Read, canonical names such as read, and MCP names such as mcp__Chrome__navigate_page map to the same safe-tool contract. It also removes Task from the auto-approve allowlist because it is not a read-only safe tool.

Regression coverage is included in tests/remote-contract-drift.test.ts.

---

Submitted with Codex.
Co-authored-by: Codex codex@openai.com