fix(cli): let a real filesystem error be itself, not "no extension pin"

[chrischall]

The one nit from #220, on a fresh branch off main — #219 merged while I was writing the fix.

clearPin reached its stem fallback by catching any throw from clearExtensionPin, on the assumption that a throw meant "that wasn't a legal server name". It also catches the failures that matter. An EACCES on the identity directory came back as:

no extension pin for @fetchproxy/example-mcp

— and because the stem lookup can never match a slash-form name, that is the message every scoped MCP gets for a permissions problem. It sends the reader looking for a file that is sitting right there, at the moment they are already locked out by a pin.

It now asks first whether the argument is a legal server name (safeIdentityFileBase, newly exported from @fetchproxy/server for it) and only falls back to the stem when it is not. Everything else propagates as itself.

Testing

The new test chmods the identity directory to 0500 and asserts the EACCES surfaces. I checked it discriminates rather than assuming: against the previous implementation it fails with exactly the misleading message above —

AssertionError: expected [Function] to throw error matching /EACCES|EPERM/
  but got 'no extension pin for @fetchproxy/example-mcp'

Skipped when running as root, where the directory mode is advisory.

1233 tests, three consecutive clean runs, tsc -b across all six workspaces.

Closes #220

[claude]

Claude finished @chrischall's task in 48s —— View job

---

Code Review: fix(cli): let a real filesystem error be itself, not "no extension pin"

Summary

This PR fixes a bug where clearPin masked real filesystem errors (like EACCES) as "no extension pin" messages. The fix properly validates whether an argument is a legal server name before attempting filesystem operations, so genuine errors propagate instead of being caught and misinterpreted.

Changes Analysis

Logic change (trust.ts:109-130):

• Validates argument with safeIdentityFileBase() first to determine if it's a legal server name
• Only falls back to stem lookup if the argument is NOT a legal server name
• Prevents the catch-all that was swallowing EACCES/EPERM errors from directory operations
• Correct behavior: scoped names like @fetchproxy/example-mcp are valid per the SAFE_SCOPED regex and proceed directly to clearExtensionPin()

Export (server/index.ts:72):

• safeIdentityFileBase is properly exported, following the convention that CLI tools can access validation helpers

Test coverage (trust.test.ts:163-181):

• Tests the exact bug: chmod directory to 0o500 and verify EACCES surfaces instead of misleading "no extension pin" message
• Correctly skips under root (where file mode is advisory)
• Cleans up permissions in finally block
• Test discriminates: confirms it fails with the old code (per PR description: "but got 'no extension pin for @fetchproxy/example-mcp'")

Validation

• safeIdentityFileBase() validation is sound: rejects empty, "..", traversal attempts, and anything outside SAFE_PLAIN/SAFE_SCOPED regexes
• Scoped MCPs work correctly: @fetchproxy/example-mcp matches SAFE_SCOPED ✓
• Ambiguous stems work correctly: @my_org_tool-mcp (no /) doesn't match either regex, falls back to stem lookup ✓
• Filesystem errors now propagate for the server-name path; only the stem-lookup path catches and translates to "no extension pin" ✓

Testing

The PR description reports: 1233 tests, three consecutive clean runs, tsc across all six workspaces. Existing tests for scoped/ambiguous stem cases (lines 122–161) remain passing and interact correctly with this fix.

---

Verdict: pass

No issues found. The fix correctly distinguishes between "not a valid server name" and "filesystem error," and the test validates the discriminator works as intended.
| Branch link

[github-actions]

✅ Auto-review verdict: pass — The fix correctly validates server names before filesystem operations, preventing real errors from being masked as "no extension pin" messages. Logic, exports, and test coverage are all sound.