Relationships
#3222 repo init writes Amp and Kiro permission settings in formats current versions no longer read
Opened by stack72 · 10/9/2026· Shipped 10/11/2026
swamp repo init / repo upgrade write agent permission settings for Amp and Kiro in formats those tools no longer read, so the grants (and any restrictions added to them) may silently do nothing on current versions.
Amp — .amp/settings.json gets amp.commands.allowlist: ["swamp *"] with strict: true (generateAmpSettingsContent / updateAmpSettings in src/domain/repo/repo_service.ts). Amp's current settings schema (https://ampcode.com/cli-settings.schema.json) has no amp.commands.* key, and Amp's docs say it does not ask for approval before running tools; command-level control now goes through plugins in .amp/plugins/ (https://ampcode.com/docs/customize/plugins). The key we write is dead.
Kiro IDE — .vscode/settings.local.json gets kiroAgent.trustedCommands: ["swamp *"] (generateKiroSettingsContent / updateKiroSettings). Kiro's IDE 0.x reference says IDE 1.0 replaced kiroAgent.trustedCommands / kiroAgent.commandDenylist with permissions.yaml shell rules and that those settings are "no longer used" (https://kiro.dev/docs/ide/0x-reference/). The 1.x workspace permissions.yaml lives outside the repo at ~/.kiro/workspace-roots/<hash>/permissions.yaml (https://kiro.dev/docs/permissions/). It is also unverified that Kiro ever read .vscode/settings.local.json rather than .vscode/settings.json.
Kiro CLI — .kiro/agents/swamp.json gets toolsSettings.shell.allowedCommands: ["swamp .*"] (generateKiroAgentConfigContent). kiro-cli 3.0 removed toolsSettings in favour of capability-based permissions rules / permissions.yaml (https://kiro.dev/docs/cli/2x-reference/, migration guide https://kiro.dev/docs/cli/v3/migration-guide/).
Expected: for each tool, swamp writes permission settings in the format the current version reads (or stops writing them where the tool has no repo-level equivalent), and repo upgrade migrates repos scaffolded with the old formats. Relevant to swamp-club#3219, which adds a read-secret deny entry to the Kiro settings above — on current Kiro versions that entry has the same problem.
Shipped
Click a lifecycle step above to view its details.
stack72 commented 10/9/2026, 6:52:47 PM
Found while fixing swamp-club#3219 (PR swamp-club/swamp#2966): that fix adds a read-secret deny entry to both Kiro configs — kiroAgent.commandDenylist [read-secret] (substring match) for the IDE and toolsSettings.shell.deniedCommands [.read-secret.] for kiro-cli. Because both still trust every swamp command (swamp * / swamp .*), the deny can be sidestepped by shell spelling that never contains the literal substring, e.g. swamp vault read""-secret or putting read-secret in a shell variable; the trust wildcard still matches, so it runs without asking. When this issue moves Kiro to its current permission format, replace the swamp wildcard trust with an explicit list of swamp subcommands (as the Claude allowlist now does) so anything not listed asks by default, rather than relying on the denylist.
Sign in to post a ripple.