fix(settings): the remote-session grants misspell the server they name

[wenzowski]

.claude/settings.json has granted mcp__Claude_Code_Remote__* — underscores — since the rules were written. The server registers as Claude-Code-Remote, with hyphens. Confirmed against the CLI's own log tree, which is keyed by the name the CLI used:

mcp-logs-Claude-Code-Remote     ← registered
mcp__Claude_Code_Remote__*      ← granted

Seven rules, matching nothing, in every episode. create_session prompted on every dispatch.

Both denials went with it. AGENTS.md bans babysitting timers and this file denies send_later and create_trigger — under a name that matches no tool, so the ban has been decorative for as long as the typo has.

Why it survived two sessions of diagnosis

The evidence looked exactly like CLOUD-178's UUID name-flip: connectors were exposed as mcp__<uuid>__*, no committed rule spelled that, and remote-session calls were denied. Commit 121de48 recorded that reading as fact. It is wrong, and one observation in those same sessions refuted it the whole time — Linear kept working under the same UUID exposure, which a missing allow rule cannot explain.

The reason is that a claude.ai connector is not governed by this allowlist. It is authorised at the connector layer; ListConnectors reports every connector connected: true, enabledInChat: true regardless of what this file says. So mcp__Linear__* is not what makes Linear work, and the name it spells never mattered.

Claude-Code-Remote is not a connector — it is absent from the connector list entirely, being the harness's own toolbox server. It is therefore the one server in this file whose rule name has to be right, and it was the only casualty. Same observation, opposite causes, and only the log tree separates them.

The gate

mcp-attach-check already reads both the settings file and the log tree, so the predicate goes there: a permission rule whose server name differs from a registered one only in separators or case. Deny rules included, for the reason above.

Narrowed deliberately, and the naive predicate is refused by a row. "A granted server that did not register" was written first and fired on mcp__claude_ai_Linear__* — the local-CLI spelling of a connector, legitimately absent in a web session. A gate that reports the portable entries as defects on every run is a gate that gets switched off, so the finding is near-miss only.

Eight new rows. One of them exists because the predicate initially sat behind an early return for "no enabled .mcp.json servers", so its first four rows passed green while it never executed — CLOUD-418's vacuity, reproduced by its own remedy. The two predicates are independent now, the restored early exit is the declared #MUTANT, and mcp-attach-check is enrolled in MUTANT_GATES.

Also repairs claim-check's own #MUTANT declaration, whose case-name substring did not match the case it names (newer vs NEWER), so mise run mutant reported names-no-case and could not prove that gate discriminates.

What this does not claim

That the corrected spelling unblocks create_session. This session is in the UUID-exposure phase, where no readable-name rule matches either, so the fix cannot be exercised here. The next session that starts in the readable phase is the test.

History

Its predecessor (#487) opened carrying a ~600-line PreToolUse name-translation mechanism built on the wrong diagnosis above. That was reset out of the branch before merging and is not in this diff. CLOUD-191, which specified it, is back in Todo and needs re-refining: its Ready predicate describes a state that already holds for reasons unrelated to any allow rule.

Closes CLOUD-665

Refs: CLOUD-178, CLOUD-191

Summary by CodeRabbit

• Bug Fixes

  • Improved validation of MCP permission rules, including detection of case and separator mismatches.
  • Validation now runs even when no enabled MCP servers are configured.
  • Duplicate permission entries and unsupported glob patterns are handled more accurately.
  • Updated a replay-related mutation description to clarify body rewrite behavior.

• Tests

  • Added coverage for valid, invalid, duplicate, denied, cross-host, and non-MCP permission scenarios.

• Chores

  • Enabled the MCP attachment validation check in the standard verification gates.

[linear-code]

CLOUD-665 The remote-session grants misspell the server they name, so every rule has matched nothing since it was written

.claude/settings.json grants mcp__Claude_Code_Remote__* — underscores. The server registers as Claude-Code-Remote, with hyphens, confirmed against the CLI's own log tree, which is keyed by the name the CLI used:

mcp-logs-Claude-Code-Remote     ← registered
mcp__Claude_Code_Remote__*      ← granted

Seven rules matching nothing, in every episode, since the rules were written. create_session prompted on every dispatch, and mem:workflow/agent-fanout plus /plan-fleet are both built on it. Both denials went the same way: AGENTS.md bans babysitting timers and this file denies send_later and create_trigger under a name that matches no tool, so the ban has been decorative for as long as the typo has.

Why it survived two sessions of diagnosis

The evidence mimicked CLOUD-178's UUID name-flip: connectors were exposed as mcp__<uuid>__*, no committed rule spelled that, and remote-session calls were denied. Commit 121de48 recorded that reading as fact and built on it; a later session built a ~600-line PreToolUse name-translation mechanism on the same reading before it was reset out.

One observation in those same sessions refuted it throughout: Linear kept working under the same UUID exposure, which a missing allow rule cannot explain. The reason is that a claude.ai connector is not governed by this allowlist at all — ListConnectors reports every connector connected: true, enabledInChat: true, so mcp__Linear__* is not what makes Linear work and the name it spells never mattered. Claude-Code-Remote is not a connector: it is absent from that list, being the harness's own toolbox server, and is therefore the one server in this file whose rule name has to be right.

Same observation, opposite causes, and nothing in the repo could separate them: mcp-allow-check reads the settings file alone, and the file is self-consistent. Only the log tree knows which names actually registered.

Refinement — Ready

Refinement gate: Definition of Ready & Done. This body carries only specializations.

• Source of truth (§1). The registered server names, read from the CLI's MCP log tree — the same directory mcp-attach-check already opens for its attachment predicate. The settings file cannot answer this about itself, which is the whole reason the defect was invisible.
• Computable predicate (§2). mise run mcp-attach-check exits non-zero on a permission rule whose server segment differs from a registered server's name only in separators or case, naming both spellings; exits 0 once the rule matches. Deny rules judged alongside allow rules, since a prohibition that names nothing is not in force.
• Effect (§3). No command-surface change. One settings correction and one new predicate inside an existing gate; no new task, because a second authority over the same two inputs is what drifts.
• Output & exit (§5). Pointer-only: the two spellings, nothing else. Exit 0 clean / 1 a rule misspells a registered server / 2 could not look. Fails open on a missing log root — no live session means no register to check.
• Commit / bump (§6). fix(settings) → patch.
• Test obligation (§7). Rows in tests/mcp-attach-check.bats for the misspelling, the corrected spelling, a case-only difference, a deny rule, dedup across rules carrying one misspelling, and a glob left to mcp-allow-check. Plus the row that refuses the naive predicate — see below. A #MUTANT declaration and enrolment in MUTANT_GATES.
• Blockers (§8). None. relatedTo CLOUD-178 (the flip, which this is not), CLOUD-191 (whose premise this refutes), CLOUD-270 (the sibling predicate in mcp-allow-check), CLOUD-418 (the vacuity discipline).

The narrowing is load-bearing, not a detail

The obvious predicate — "a granted server that did not register" — is wrong and was written first. It fires on mcp__claude_ai_Linear__*, the local-CLI spelling of a connector that legitimately registers nothing in a web session. A settings file is shared across hosts, so that predicate reports the portable entries as defects on every run, which is the false-positive rate that gets a gate switched off.

The defect is a near miss: a rule naming a server that is here, under a spelling differing only in separators or case. That is never intentional, and it cannot be confused with a cross-host entry — fold out separators and case, and Claude_Code_Remote collides with Claude-Code-Remote while claude_ai_Linear collides with nothing. A test row must fail the naive version.

Done

• The grants name the registered server, and mise run mcp-attach-check reports no misspelling against a live session.
• A rule differing from a registered name only in separators or case fails the gate and names the correct spelling; a legitimately-absent cross-host rule does not.
• The mutation is declared and caught by mise run mutant.
• Whether the corrected spelling actually admits create_session is observed and recorded, not assumed — it cannot be tested from a session already in the UUID-exposure phase, so the reading comes from the next session that starts in the readable phase. Recorded on CLOUD-178, which is the evidence thread.

CLOUD-178 claude.ai connector tools flip between readable and UUID names, silently breaking the permission allowlist

Split out of CLOUD-177, which is Done on its own scope. Evidence thread: the comments on CLOUD-177, in particular the final correction establishing verdict (a).

Ready

A claude.ai connector MCP server is exposed to a session under two different names over its lifetime, and a permission allow rule can only name one of them.

At session start the Linear connector appears as mcp__Linear__*. On a mid-session disconnect/re-register it comes back as mcp__4db58e41-cd4e-4818-8922-46cf616593f4__*, and the readable tools vanish from the listing entirely. .claude/settings.json allows "mcp__Linear", a prefix match, which matches nothing under the UUID name. Every Linear call then prompts for approval, with no signal that anything changed.

This hits the board-in-lockstep rule directly: moving a CLOUD-* issue between states is a save_issue call, so the workflow AGENTS.md mandates starts requiring a human tap per transition, mid-session, without warning.

Measured, across two containers

	d38efda7	047c8272
At session start	readable	readable
After reconnect	UUID	UUID
Linear UUID	4db58e41-cd4e-4818-8922-46cf616593f4	same
Gmail UUID	d648a34b-ef40-4201-b1af-9123d05d7a1e	same
Xero UUID	0c388dc8-630a-4020-96c7-ff71ce1af383	same

Verdict: the UUID is stable and equal across containers. It is a durable identity for the connector; what varies is which of the two names is live at a given moment. This was initially mis-called as "unstable per boot" from a session that had not yet reconnected — absence of a reconnect is not evidence of naming stability, and any future measurement here needs to span at least one reconnect to say anything.

Confirmed load-bearing, not cosmetic: a save_issue under mcp__4db58e41-…__save_issue prompted, while a Linear write under the readable name moments earlier did not. (Both prompt-or-not observations are human-reported — an agent cannot observe its own approval prompts, and asserting otherwise is what made this take four passes to get right.)

Note this is a second, independent defect from the one that originally masked it: an org-level ask control on the Linear connector was overriding allow rules entirely, per Organization controls on connector tools. That control has been cleared and verified. Clearing it is what made this defect visible.

Ready predicate

A session survives a connector reconnect with Linear calls still auto-approved — no prompt on a save_issue issued under either the readable or the UUID name.

Done (proposed)

• ~/.claude/settings.json allows both names:

"mcp__Linear",
"mcp__4db58e41-cd4e-4818-8922-46cf616593f4"

• User-level, not the repo. A connector UUID is an account-specific identifier: meaningless to any other contributor or fork, and silently rotting if the connector is re-authorized. Repo rule 1 keeps those out of committed config. .claude/settings.json keeps "mcp__Linear" alone — correct and portable for anyone cloning batten — and the UUID lives in the personal scope where account facts belong.
• Verified by observation across a reconnect, human-reported, not inferred from a session with no reconnect in it.

Open questions

• Does the UUID survive re-authorization of the connector? Stable across two containers is not stable across an OAuth re-grant. If it rotates there, the user-level entry needs re-deriving and the failure mode returns silently. Worth knowing before treating this as closed.
• Gmail and Xero have the same exposure and are not covered by any allow rule today. Not in scope here, but the same two-name fix applies if either is ever allowlisted.
• No gate is possible for this one. Repo rule 2 wants a rule to ship with a runnable mechanism, and there is none available: the failure lives in a settings file outside the repo, keyed to an identifier the repo must not contain, and triggered by a remote-host event. Worth stating explicitly rather than leaving as an unmet obligation — this is a documented limitation, and the compensating control is that the failure is loud to the human (a prompt) even though it is silent to the agent.

Why the repo cannot fix this itself

In Claude Code on the web, connectors are "provisioned by the remote host and arrive as explicit --mcp-config entries" (MCP docs), which is also why they appear as mcp__Linear__* rather than the documented mcp__claude_ai_<server>__<tool> form. The naming is chosen per registration episode by the host, not by anything under this repo's control. The durable upstream fix would be a stable server name across re-registration, or permission matching on server identity rather than exposed tool-name prefix; until then, allowlisting both names is the available mitigation.

---

Generated by Claude Code

CLOUD-191 Self-heal the connector allowlist at session start from the host-injected MCP config

Ready

There is no durable machine. Every session runs in a container that is reclaimed, so a fix written to ~/.claude/settings.json by a session does not survive it, and a fix written by hand has nowhere permanent to live. CLOUD-178's mitigation is therefore unreachable as stated: the only durable surfaces are this tracker and the repo.

The connector's exposed name is chosen per registration episode, and observation now shows the flip is bidirectional — a single session went readable → UUID → readable. So the failure has no monotone boundary: an allowlist naming only the readable form is correct during whichever episodes land on it, and silently denies every Linear call during the others.

The identity is discoverable, so no identifier needs committing

The host writes its injected MCP configuration to /tmp/mcp-config-cse_<session>.json, and that file keys connectors by UUID — the readable mcp__Linear__* is a display alias over it. Measured in one session, 5 servers, connectors keyed as 4db58e41-…, d648a34b-…, 0c388dc8-…, bf7c680d-…, plus github.

That makes a self-healing repair possible with no account-specific identifier in git: read the injected config, derive the server keys present, emit allow rules for them. The mechanism is portable to any account and any fork, and it repairs whichever name the current episode chose.

Ready predicate

A session that receives connectors under a name no committed allow rule matches reaches a state where Linear calls are permitted, without a human editing settings and without any UUID appearing in a tracked file.

Blockers (§8)

None.

Open questions, in the order they gate the work

1. ~~Does a ~~~~SessionStart~~ hook's write to settings affect the session that is starting? MOOT, and the design changed rather than the question being answered. mem:connector-allowlist-recovery refutes the whole shape in its own words: "anything that resolves a tool name once and caches it for the session is wrong for part of that session by construction — including an allow rule written at startup, which is what CLOUD-191 proposes." The flip happens mid-session and is bidirectional, so a startup write is wrong for whichever episodes follow it no matter when it lands. Shipped as a PreToolUse resolution instead, per call: nothing is written, so nothing has to land in time. The startup-ordering question is no longer on any path.
2. What causes the flip? Unknown. No hypothesis is currently supported by evidence; the observed sequence is readable at start, UUID after a mid-session disconnect, readable again after a further re-register.
3. Does the UUID survive an OAuth re-grant? Carried over from CLOUD-178. If it rotates, a committed UUID would rot silently — which is a further argument for deriving it rather than storing it.

RETRACTED — nothing shipped, and the section below described a fix for a defect that was not happening

Everything from here to the end of the "Done" list is withdrawn. It was written, committed, and reset out of the branch before merging; no connector-allow-resolve, no connector-allow-guard, no suites. What follows the retraction is kept verbatim rather than deleted, because the reasoning error is the useful part.

The defect that was actually denying create_session is a typo, and it is not this issue. .claude/settings.json granted mcp__Claude_Code_Remote__* with UNDERSCORES; the server registers as Claude-Code-Remote with HYPHENS, confirmed against the CLI's own log tree (mcp-logs-Claude-Code-Remote). Those rules matched nothing in any episode, readable or UUID. Fixed on the branch, with a near-miss predicate added to mcp-attach-check so the class cannot recur.

Why this issue's premise does not survive. It reasons that the flip "silently denies every Linear call" during UUID episodes. It does not, and never did: a claude.ai connector is not governed by permissions.allow at all — ListConnectors reports every connector connected: true, enabledInChat: true, and Linear worked through both phases of the 2026-08-18 session under a name no committed rule spells. Claude-Code-Remote is not a connector; it is absent from the connector list entirely, which is why it was the only casualty and why its rule's spelling was load-bearing.

So the Ready predicate is unreachable as written — "a session that receives connectors under a name no committed allow rule matches reaches a state where Linear calls are permitted" describes a state that already holds for reasons unrelated to any allow rule. Back to Todo, unassigned, and it needs re-refining against what is now known before anyone builds again. What may remain: whether the toolbox server's rule matching survives a mid-session flip once the spelling is right. That is a real question and it is much smaller than this issue.

---

RETRACTED: What shipped, and where it differs from the specification above

The premise held and the mechanism changed. The Ready block reasoned that the live identity is discoverable, so nothing account-specific needs committing — correct, and the missing half was which discoverable thing to anchor on. Not the key: each entry's url carries the connector's real upstream endpoint in its mcp_url query parameter (https://mcp.linear.app/mcp, https://api.anthropic.com/v1/code/mcp/meta), a public vendor address that is stable across containers and identical for every account, and therefore committable where the key beside it is not.

• mise-tasks/connector-allow-resolve — endpoint → the portable alias the committed .claude/settings.json already spells → the verdict that file already states.
• mise-tasks/connector-allow-guard — the PreToolUse adapter, wired on matcher ^mcp__.
• tests/connector-allow-resolve.bats, tests/connector-allow-guard.bats — both enrolled in MUTANT_GATES, so each carries a declared corruption its own suite is proven to catch.

It is a name translation, not a grant. allow only where the committed file already allows that exact verb on that connector; deny wherever it denies one — an arm strictly stricter than before, since a literal deny rule misses a flipped name exactly as a literal allow rule does, leaving the two denied Claude_Code_Remote verbs unenforced. Everything else is silence and the normal permission flow decides. Nothing is written, cached, or persisted.

Done

• A tracked hook applies the committed connector permissions to whichever server name the host chose, without a human editing settings. ✅ — PreToolUse rather than SessionStart, for the reason recorded against open question 1.
• No UUID or other account-specific identifier appears in any tracked file (rule 1 holds). ✅ — asserted by a suite row that greps the resolver for a UUID shape, and the fixtures use synthetic keys with real public endpoints.
• A gate asserts the derivation against a fixture config. ✅ — 26 rows over four connector shapes, plus the two mutation declarations.
• The observed behaviour of open question 1 is recorded. ✅ — above, and the session's live-key measurements are on CLOUD-178.

RETRACTED — this residue was residue of the retracted mechanism. CLOUD-663 is being closed as not-a-finding: the memory text it carries describes the same wrong model. The underlying observation it made — that the protected-path gate's redirect names a surface which may not have attached — is real and stands on its own, and is recorded there. Original text follows.

~~mem:connector-allowlist-recovery~~~~ still describes the superseded design and cannot be corrected from this session:~~ the protected-path gate routes memory writes through Serena's write_memory, and mise run mcp-attach-check reports serena CONNECT_TIMEOUT, so the sanctioned surface did not attach. Filed as CLOUD-663 with the full replacement text attached as a comment, to be applied verbatim.

Watch: what a later session needs to pick this up

The trigger is not observable to an agent as a prompt — an agent cannot see its own approval prompts. What it can observe:

• Which connector server names are live, from the injected config and from the tool listing.
• Whether a Linear call returns a denial.

So the observation to record, each time it is taken: the session's live connector keys, which form the tool names took, and whether a call succeeded or was denied. Appended to CLOUD-178, which is the evidence thread and is durable when the container is not.

That series is what open question 2 needs. It cannot be answered from a single session, and no session so far has recorded it in a form the next one can read.

Review in Linear

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: dfadda52-ca51-4e8c-9d55-29d0206308ff

📥 Commits

Reviewing files that changed from the base of the PR and between 2f9764b and 14ce1a5.

📒 Files selected for processing (5)

• .claude/settings.json
• mise-tasks/claim-check
• mise-tasks/mcp-attach-check
• mise.toml
• tests/mcp-attach-check.bats

Included review availability: Your plan includes up to 3 reviews per rolling hour; 1 remains after this review.

---

📝 Walkthrough

Walkthrough

The change aligns Claude Remote MCP permission identifiers and extends mcp-attach-check to detect misspelled allow and deny server names against registered session servers. Tests cover normalization, duplicates, globs, unmatched servers, and empty-server handling.

Changes

MCP permission validation

Layer / File(s)	Summary
Permission identifier alignment .claude/settings.json	Remote MCP tool identifiers now use hyphen-separated server names in allow and deny rules.
Permission rule validation and coverage mise-tasks/mcp-attach-check, tests/mcp-attach-check.bats, mise.toml, mise-tasks/claim-check	The check validates normalized allow and deny server names against session log entries, continues when no enabled servers exist, and reports both validation results. Bats tests cover spelling, case, duplicates, globs, unmatched servers, and diagnostic output. Mutation coverage and the replay annotation are updated.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Merge Risk: ⚪ Minimal · up to 14ce1

The permission-name correction and associated checks introduce no actionable merge-blocking risk at the current head; the PR is merge-ready after normal checks and review.

Sequence Diagram(s)

sequenceDiagram
  participant mcp-attach-check
  participant PermissionSettings
  participant SessionLogTree
  mcp-attach-check->>PermissionSettings: Read allow and deny MCP rules
  mcp-attach-check->>SessionLogTree: Read registered server names
  SessionLogTree-->>mcp-attach-check: Return server directories
  mcp-attach-check->>mcp-attach-check: Normalize and compare names
  mcp-attach-check-->>PermissionSettings: Report near-miss names

Loading

Suggested reviewers: claude

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the settings fix for misspelled remote-session MCP server names, which is a key change in the pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch wenzowski/cloud-665-the-remote-session-grants-misspell-the-server-they-name-so

Warning

Review ran into problems

🔥 Problems

These MCP integrations need to be re-authenticated in the Integrations settings: Linear

---

_{Comment @coderabbitai help to get the list of available commands.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[wenzowski]

/fast-forward