fix(extension): fail closed on the recordDestructive/sync setting fallback

cfg.get(...) fallbacks for mcp.categories.recordDestructive and .sync were
still `true`, contradicting Task 1's intent that both default off. Inert
today (package.json registers a real default of false, which wins), but
would silently widen if that settings block were ever renamed/unregistered.
Flip both to `false`.

docs(mcp-server): document the LEGACY_CATEGORIES_DEFAULT_ON granularity ceiling

LEGACY_CATEGORIES_DEFAULT_ON gates absent tools-config.json keys by
category, not tool name — so a standalone npm user with an on-disk custom
profile who explicitly disabled Record Write can silently regain a *new*
tool added to that already-adopted category (upload_attachment, and
create_records/update_records if they postdate the user's config). Never
affects delete_records (record-destructive is a new category, correctly
excluded) and never affects VS Code extension users (syncSettingsToFile
always writes an explicit key for all 71 tools). Strictly better than
pre-pass behavior, which had no category gate at all. No resolution logic
changed — documents the known limitation in CHANGELOG.md for npm
consumers and adds a ponytail: comment at the allowlist definition naming
the ceiling and the upgrade path (a frozen tool-name allowlist).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: ARHAEEM

packages/extension/src/mcp/tool-profile.ts

@@ -270,15 +270,15 @@ export class ToolProfileManager implements vscode.Disposable {
       tableDestructive:       cfg.get('mcp.categories.tableDestructive',       true),
       fieldWrite:             cfg.get('mcp.categories.fieldWrite',             true),
       fieldDestructive:       cfg.get('mcp.categories.fieldDestructive',       true),
-      recordDestructive:      cfg.get('mcp.categories.recordDestructive',      true),
+      recordDestructive:      cfg.get('mcp.categories.recordDestructive',      false),
       viewWrite:              cfg.get('mcp.categories.viewWrite',              true),
       viewDestructive:        cfg.get('mcp.categories.viewDestructive',        true),
       viewSection:            cfg.get('mcp.categories.viewSection',            true),
       viewSectionDestructive: cfg.get('mcp.categories.viewSectionDestructive', true),
       formWrite:              cfg.get('mcp.categories.formWrite',              true),
       extension:              cfg.get('mcp.categories.extension',              true),
       recordWrite:            cfg.get('mcp.categories.recordWrite',            true),
-      sync:                   cfg.get('mcp.categories.sync',                   true),
+      sync:                   cfg.get('mcp.categories.sync',                   false),
     };
     return {
       profile,

packages/mcp-server/CHANGELOG.md

@@ -2,6 +2,49 @@
 
 ## [Unreleased]
 
+### Known limitations (2026-07-25 tool profile safety — standalone CLI users)
+
+- **`LEGACY_CATEGORIES_DEFAULT_ON` is category-granular, not tool-name-granular —
+  a *new tool in an already-adopted category* can still be silently regained.**
+  This only affects **standalone `airtable-user-mcp` npm/CLI users** with a
+  hand-edited or pre-existing `~/.airtable-user-mcp/tools-config.json` on
+  `activeProfile: "custom"` — **not** the VS Code extension, whose
+  `syncSettingsToFile()` always writes an explicit `true`/`false` for all 71
+  tools, so it never hits the absent-key resolution path described below.
+  - **Who's affected:** a standalone user who set `activeProfile: "custom"` and
+    explicitly turned the **Record Write** category off (`table-write`,
+    `field-write`, `view-write`, etc. are equally affected — Record Write is
+    just the concrete case that shipped on this branch) before this branch's
+    new tools existed in their on-disk config.
+  - **What they gain:** on upgrade, `upload_attachment` (new tool) — and
+    `create_records`/`update_records` if those also postdate their config —
+    resolve their absent `customTools` key to *enabled*, because
+    `LEGACY_CATEGORIES_DEFAULT_ON` allowlists the whole `record-write`
+    *category* (frozen at the 13 categories that existed when per-tool
+    overrides were introduced), not the individual tool names within it. A
+    tool with no key at all is judged solely by whether its *category* is
+    legacy — it has no way to know the user's config predates the *tool*
+    specifically, only the *category*.
+  - **What they do NOT gain:** `delete_records` — `record-destructive` is a
+    brand-new category on this branch and is correctly excluded from the
+    allowlist, so it resolves absent keys to disabled as intended. Only
+    record-**write** tools are affected, never destructive ones.
+  - **Net effect vs. pre-hardening-pass behavior:** strictly better. Before this
+    pass, ALL new tools (including `sync_base` and `delete_records`) resolved
+    absent keys to enabled with no category gate at all; this pass closed that
+    for every *new category*. The residual is narrower: only new *tools* inside
+    a category the user had already adopted (and then explicitly disabled) can
+    still slip through.
+  - **Remedy:** re-run `manage_tools` (`get_tool_status` to see what's enabled,
+    `toggle_tool`/`toggle_category` to turn `upload_attachment` back off if
+    unwanted) or hand-edit `~/.airtable-user-mcp/tools-config.json` to add an
+    explicit `"upload_attachment": false` entry. The real fix — a frozen
+    tool-**name** allowlist alongside (or instead of) the category allowlist —
+    is deliberately deferred: it is a semantic change to credential-adjacent
+    tool-gating logic and does not belong in the closing commits of a
+    pre-merge hardening pass. See the `ponytail:` comment on
+    `LEGACY_CATEGORIES_DEFAULT_ON` in `src/tool-config.js`.
+
 ### Changed (2026-07-25 tool profile safety, pre-merge hardening pass)
 
 - **`safe-write` no longer includes `sync_base`.** `sync_base` reaches

packages/mcp-server/src/tool-config.js

@@ -153,6 +153,19 @@ export const CATEGORY_LABELS = {
  * custom profile" invariant is self-maintaining and can't be forgotten by a
  * future change the way a hand-maintained "which categories are new" list
  * could be. See CLAUDE.md's "Keeping tool categories in sync" checklist.
+ *
+ * ponytail: this allowlist is CATEGORY-granular, not tool-name-granular — its
+ * ceiling. A new tool added to an already-legacy category (e.g. `upload_attachment`
+ * / `create_records` / `update_records` joining `record-write`) is indistinguishable
+ * here from a tool that predates the config; both resolve an absent key to enabled.
+ * So a standalone npm user with an on-disk `custom` profile who explicitly turned
+ * a legacy category off can silently regain a *new* tool in that category on
+ * upgrade (never a new category — that's what this allowlist does guard). Affects
+ * `airtable-user-mcp` CLI users only: the VS Code extension's `syncSettingsToFile`
+ * always writes an explicit key for every tool, so it never hits the absent-key
+ * path. See packages/mcp-server/CHANGELOG.md for the specific case this shipped
+ * with. Real fix: freeze a tool-NAME allowlist instead of (or in addition to) this
+ * category allowlist — deferred as a deliberate scope cut, not an oversight.
  */
 const LEGACY_CATEGORIES_DEFAULT_ON = Object.freeze(new Set([
   'read', 'record-read',