Cannot save existing MCP server config while duplicate config can be created

[peicodes]

Slack feedback: Can't save an MCP server config, but can create a new one with the exact same config JSON. Is it related to secrets? Kinda confusing why and what I can do about it, or if it's a bug.

Slack message: https://warpdev.slack.com/archives/C08KTPNQN65/p1774610414964769

Requested follow-up:

• Reproduce editing/saving an existing MCP config vs creating a new one with identical JSON
• Verify whether secret handling/redaction causes save to fail
• Improve UX/error messaging so users understand why save failed and how to recover

---

Linear: APP-3657

[oz-for-oss]

@peicodes

Here's what I found while triaging this issue:

• This appears to be a save-path inconsistency: editing an existing MCP config runs a secret-redaction check that creation does not.
• Related issue MCP: Cannot define MCP Server because of secret redaction #8761 covers secret-redaction blocking MCP definition, but this report is narrower because creating a duplicate can succeed with the same JSON.

I have a few follow-up questions before I can narrow this down:

1. Can you attach a screenshot or short recording of the failed Save state or toast, with any secrets redacted?
2. Can you share the MCP config shape with secret values replaced by placeholders, especially whether the token appears in env, headers, url, or another field?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that existing MCP config saves can be blocked by the edit-path secret-redaction check even though creating a new MCP server from the same JSON bypasses that check..

Triage

This looks like a real MCP settings bug rather than expected validation behavior. The key code-path difference is that saving an existing templatable MCP server runs secret detection and aborts on a match, while adding a new MCP server from JSON does not run that same check before creating the template/installation. That matches the reported symptom: the same JSON can fail on Save for an existing server but succeed when entered as a new/duplicate server.

Likely implementation areas:

• app/src/settings_view/mcp_servers/edit_page.rs handles the MCP settings edit page, including detect_secrets_in_templatable_mcp_server, parse_templatable_json, handle_save_templatable_mcp_server, and the separate new-server Save branch.
• app/src/ai/mcp/parsing.rs templatizes env and headers values and creates the installation variable values; values outside those fields can remain in the template JSON and may still be caught by secret redaction.
• app/src/ai/blocklist/block/secret_redaction.rs provides the detector used by the edit save path.

I found related but not duplicate issues: #8761 covers secret redaction blocking MCP definition with an explicit bearer token, #9807 covers clearer MCP config parse/startup errors, and #7694 covers broader MCP editor/save UX problems. This issue should remain distinct because it specifically reports an edit-save vs new-create inconsistency for identical JSON.

Question reasoning

1. Can you attach a screenshot or short recording of the failed Save state or toast, with any secrets redacted? — The report does not include the exact visible error, and a screenshot/video would confirm whether the failure is the secret-detection toast or another save-path error.
2. Can you share the MCP config shape with secret values replaced by placeholders, especially whether the token appears in env, headers, url, or another field? — The parser templatizes env and headers differently from other fields, so the field containing the secret materially affects the suspected root cause without requiring the reporter to disclose the secret.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz