MCP Write Approvals — In-Chat & Always Allow

The Rule

Every mutating MCP tool (ssh_exec_command, sql_execute_write, ftp_write_file, api_send_request, task and connection creation, …) requires a real human Allow/Deny before it runs. The model can never approve its own write — there is no confirm token or override parameter.

Where the Buttons Appear

1. In the agent's own chat (MCP elicitation): clients that render elicitation — the Claude Code terminal CLI and Claude Desktop — show Allow once / Always allow this tool / Deny directly in the conversation.
2. Fallback window: clients with no elicitation UI (e.g. the Claude Code VSCode extension, headless runs) fall back to VORTΞXHQ's always-on-top approval window. A timeout or auto-declined prompt never auto-allows — it falls back so a human button always exists somewhere.

Tip for Claude Code users: Claude Code shows its own per-tool permission prompt in the chat as well. If you rely on that prompt (or add the write tools to permissions.ask in your Claude settings), you can mark the tools "Always allow" in VORTΞXHQ and keep exactly one approval — in the chat.

Always Allow

• Choosing Always allow this tool stores a per-tool opt-out, so that tool stops asking.
• Manage the list in Settings → Agent Access (MCP) → Always-allowed tools; remove a chip to be asked again.
• The global Confirm every change toggle turns the gate on/off for all tools and all clients at once — prefer per-tool Always allow.

What Approval Can Never Allow

Catastrophic operations are refused before any prompt and cannot be approved at all: DROP/TRUNCATE, DELETE/UPDATE without WHERE, GRANT/REVOKE, disk-wiping shell commands (rm -rf /, mkfs, dd of=/dev/…), and similar. These are permanent capability limits of the MCP interface, not policies.

Secrets

Passwords, private keys and tokens never travel over MCP. Every outgoing result is sanitized, and a hard wall scans responses for any decrypted secret value and blocks the entire reply if one would leak.