#3219 Should repo init's allowlist include swamp vault read-secret, with auditReads off by default?

Opened by taylor · 10/9/2026· Shipped 10/9/2026

PR #2966: https://github.com/swamp-club/swamp/pull/2966

swamp repo init writes Bash(swamp vault:*) to .claude/settings.local.json, which also allows swamp vault read-secret. Vaults are created with auditReads off. So in a freshly set-up repo, Claude Code can print any secret's value without asking, and the vault's audit trail doesn't record it. Only the shell-level swamp audit hook sees the command.

Would it make sense to either:

narrow the allowlist, so read-secret asks the user first, or
turn on auditReads by default for new vaults, or have repo init / vault create mention the setting?

Found while writing training material for new swamp users. Tested on 20261009.154711.0.

02Bog Flow

Shipped

10/9/2026, 6:56:08 PM

Click a lifecycle step above to view its details.

03Sludge Pulse

swamp_lord assigned swamp_lord10/9/2026, 5:50:23 PM

stack72 assigned stack7210/9/2026, 5:55:17 PM

system commented 10/9/2026, 5:47:08 PM

Classified automatically when this issue was filed.

Type: Security

This reads like a security report, so it is now visible only to you and admins.

If you feel this classification is incorrect, add a ripple to tell us so.

swamp_lord commented 10/9/2026, 6:31:44 PM

Approved plan: ask before read-secret, on repo init only

swamp repo init will add one new section, permissions.ask, to the .claude/[HOST-1].json it generates. The existing allow list and hooks stay as they are:

{
  "permissions": {
    "allow": [
      "Bash(swamp vault:*)",
      "...rest unchanged..."
    ],
    "ask": [
      "Bash(swamp vault read-secret:*)"
    ]
  },
  "hooks": { "...unchanged...": [] }
}

Claude Code checks rules in the order deny, then ask, then allow, so:

Command	Result
`swamp vault list` / `put` / `inspect` / other vault subcommands	runs without prompting, as today (allow `swamp vault:*`)
`swamp vault read-secret <vault> <key> --json`	Claude Code asks the user first
`swamp --json vault read-secret ...` (global flag first)	matches neither rule, so it also asks

Who gets it: only a brand-new .claude/[HOST-1].json written by repo init on a fresh repo. Existing repos, repo upgrade, repo init --force, and settings files that already exist are deliberately left alone, so current installations behave as before. Users can add the ask entry by hand to opt in.

Out of scope: auditReads stays off by default for new vaults, and Kiro trusted commands are unchanged.

Limits: it is a confirmation prompt, not a hard barrier. It does not apply in Claude Code bypass-permissions or auto mode, and a user can delete the entry.

stack72 commented 10/9/2026, 6:56:12 PM

Thanks @taylor for reporting this! We shipped: swamp repo init/upgrade pre-approves swamp vault read-secret for agents: Claude Code via Bash(swamp vault:*), Kiro IDE via trustedCommands swamp , kiro-cli via allowedCommands swamp .. Claude gets explicit vault entries without read-secret (upgrade removes the legacy wildcard); Kiro IDE gets a commandDenylist entry so read-secret asks; kiro-cli gets a deniedCommands entry so the agent cannot run it.. The fix has been merged and a release is on its way. We appreciate your contribution to swamp.