Follow up Amp upstream updates: emit amp.permissions (allow/ask/reject) instead of dropping non-deny rules

[dyoshikawa]

Summary

rulesync's Amp permissions adapter only emits amp.tools.disable (a coarse disable-only list), so allow and ask rules are silently dropped and argument-level patterns are collapsed to the bare tool name. Amp has a richer declarative permission model (amp.permissions) that can express all three actions plus argument matchers, which rulesync does not emit.

Recent Releases

• Tool-level permissions announced 2025-08-07: https://ampcode.com/news/tool-level-permissions
• Amp manual (amp.permissions, amp.guardedFiles.allowlist, amp.dangerouslyAllowAll activate the declarative permissions plugin): https://ampcode.com/manual
• MCP permissions (amp.mcpPermissions, related but separate gating surface): https://ampcode.com/news/mcp-permissions (2025-08-25)

Gaps

• permissions — project + global (partial / lossy). Upstream amp.permissions is an array of entries { tool, matches: { cmd }, action } where action ∈ allow | reject | ask | delegate, supports tool-name wildcards (*, mcp__*) and per-argument glob matchers (matches.cmd), first-match-wins. rulesync's src/features/permissions/amp-permissions.ts maps only deny → amp.tools.disable[] (tool name), dropping allow/ask rules with a warning and discarding the per-pattern glob. So rulesync's {category: {pattern: action}} model does not round-trip: ask/allow data is lost, and deny patterns lose their argument specificity.

Proposed Follow-up

• Emit amp.permissions (array form) so rulesync's permission model round-trips fully:
  • deny → { tool, matches: { cmd: <pattern> }, action: "reject" } (keep amp.tools.disable only for the bare whole-tool "*" case if desired)
  • ask → action: "ask" (currently dropped)
  • allow → action: "allow" (currently dropped)
  • Preserve the per-pattern glob in matches instead of collapsing to the tool name.
• Keep the schema loose (project convention) and retain the existing shared-settings.json merge / no-delete guard.
• Note: amp.permissions is documented as activating Amp's internal (legacy-compat) permissions plugin but remains functional; confirm the active settings file (settings.json vs settings.jsonc, see Amp settings-file extension divergence: MCP defaults to settings.jsonc, permissions to settings.json (splits config) #1989) when wiring output.

References

• https://ampcode.com/news/tool-level-permissions — primary announcement of the amp.permissions model and action vocabulary.
• https://ampcode.com/manual — current manual documenting amp.permissions entry schema and guarded-files settings.
• https://ampcode.com/news/mcp-permissions — amp.mcpPermissions (adjacent MCP-gating surface, noted for completeness).

[dyoshikawa]

Research update — needs a maintainer design decision before implementing

I fact-checked this against Amp's primary sources (June 2026). Summary:

The gap is real. src/features/permissions/amp-permissions.ts maps only deny → amp.tools.disable[] (bare tool name), so allow/ask rules are dropped and deny patterns lose their per-argument specificity. Confirmed by reading the adapter.

The proposed amp.permissions schema is real and matches the issue. Entries are { tool, action, matches } with action ∈ allow | reject | ask | delegate, tool-name globs (*, mcp__*), per-argument matchers (matches.cmd), first-match-wins.

• https://ampcode.com/news/tool-level-permissions
• https://ampcode.com/manual/appendix/legacy-permissions-rules.txt

But amp.permissions is officially legacy-compat, and Amp is migrating away from it. The manual's legacy-permissions-rules reference states it "supports legacy permissions syntax for backwards compatibility," that "Amp's permission behavior is moving to a plugin," and "For new permission hooks, prefer the Plugin API" (amp.on('tool.call', ...) JS handlers). amp.tools.disable (what rulesync emits today) remains a current, non-deprecated surface.

• https://ampcode.com/manual
• https://ampcode.com/manual/appendix/legacy-permissions-rules.txt

Why this needs your call (not auto-resolved)

Implementing the proposal would have rulesync emit a declarative format that upstream explicitly labels legacy/backwards-compat and is actively superseding with a JS Plugin API (which is out of scope for rulesync's declarative permissions feature). That is a product/strategy decision, not a pure bug fix:

• Option A — implement amp.permissions array output now (fixes the allow/ask data loss immediately, but ships a format Amp is deprecating).
• Option B — wait, since Amp is moving permissions to the Plugin API; keep the current amp.tools.disable-only behavior for now.
• Option C — emit amp.permissions only for the lossy cases (allow/ask/argument-specific deny) while keeping amp.tools.disable for whole-tool deny, and document the legacy-compat caveat.

Leaving this open for a maintainer decision on which direction to take. Happy to implement whichever you pick.