Warn on likely-typosquat npm installs in the bash tool permission prompt

[AyoubTadlaoui]

Gap

The bash tool already gates global package installs (npm install -g, pnpm add -g, yarn global add, pip install --user, cargo install, go install). But project-local installs, npm install <pkg>, npm i, yarn/pnpm/bun add, and npx/bunx/pnpm dlx runners, run after a generic "Execute command" prompt that gives no signal about what is being pulled in. A single mistyped name (npm install lodahs instead of lodash) is a classic supply-chain attack.

Proposal

An offline, deterministic check that parses npm/yarn/pnpm/bun install and runner commands out of the shell command and flags any target package whose name is exactly one edit from a curated popular package. On a hit it enriches the existing permission.Request prompt (for example: "Install suspected typosquat: lodahs, did you mean lodash?") so the human can verify before allowing. It never hard-denies on its own (unlike the existing global-install BlockFuncs) and adds no dependencies.

Design:

• Pure/offline/deterministic. Gate: Optimal String Alignment (restricted Damerau-Levenshtein) distance == 1 and popular name length > 4.
• Hardening: sub-command splitting (;/&&/||/|/&/newlines), env-assignment + wrapper prefixes (sudo, env ...), quote stripping, global-option skip, value-flag skip (so npm install --prefix axio lodash does not false-flag axio), @scope/pkg@version normalization.

It sits next to the existing install-gating in internal/agent/tools/bash.go and routes through permission.Request rather than a hard-deny BlockFunc, so the human stays in control. I have a working implementation + table tests ready (go test, go vet, gofmt clean) and proposed the same check upstream in Goose: aaif-goose/goose#9642. Happy to open the PR (I'll sign the CLA).

[rpelevin]

Putting this in the permission prompt rather than a hard deny feels right. The human still owns the decision, but the prompt now carries the specific supply-chain context needed to make that decision.

I would make the enrichment part of the approval record, not only the display text. For each flagged command, preserve:

• approval id;
• raw command hash;
• parsed subcommand segment;
• package manager;
• normalized package name;
• requested version or runner target, if present;
• suspected popular package;
• edit-distance reason;
• parser rule version;
• redacted prompt snapshot hash;
• requested_at / decided_at;
• decision: allow, deny, revise;
• consumed_at.

That makes later audit possible: "the user allowed this exact command after seeing a suspected typosquat warning," instead of just "the user allowed Bash."

Tests I would add:

1. npm install lodahs flags lodash.
2. scoped packages and versions normalize correctly.
3. npm install --prefix axio lodash does not flag the option value.
4. wrapper prefixes like sudo, env, npx, bunx, and pnpm dlx parse consistently.
5. chained commands split correctly across ;, &&, ||, pipes, ampersands, and newlines.
6. the check is deterministic/offline and does not call the network.
7. approval of one raw command hash cannot be reused for a modified command.
8. any future "always allow" path does not become blanket approval for all package installs.

That keeps the approval gate narrow: enrich this exact shell request, then bind the user's decision to the exact command they saw.

[AyoubTadlaoui]

@rpelevin Thank you for your insight

Yes, that's the intent. The check just enriches the permission prompt and the human still makes the call. The existing BlockFuncs are there for the global installs that are almost always wrong; this one is softer, more "you sure that's the package you meant."

The approval-record point is a good one, and I'd build it in two steps so the security part lands before the bookkeeping.

The part that actually matters: bind the approval to the exact command. The decision covers one normalized command, keyed by its hash, used once.
Approve npm install lodahs, then a second package gets tacked on, the hash stops matching and it re-prompts. And if an "always allow" path ever shows up, it has to stay scoped to the flagged (subcommand, package), never "allow every install", otherwise the gate isn't really doing anything. Those are the two I'd pin in tests (your 7 and 8).

The record itself I'd keep small to start:

• approval id;
• command hash;
• parsed install target (manager, normalized name, version or runner);
• typosquat reason (suspected package, edit distance, parser rule version);
• decision;
• requested_at / decided_at / consumed_at.