aikido ignore rule not working: finding still reported after aikido

Not specified by the original author.

TL;DR

An aikido ignore is how you tell Aikido Security to stop reporting a finding you have reviewed and accepted. The code-based route is a .aikido file at your repository root: use it to exclude paths (the exclude/paths key hides files from secrets, SAST, lockfile, code-quality, and Deep Review scans) and to ignore specific CVEs with a written reason, which the Aikido UI then shows next to the ignored CVE. Path matching is simple string inclusion, not globs: if the literal value you write appears anywhere in the full file path, the file is excluded, and wildcards or regular expressions are not supported.

Use this when

• An Aikido finding is a false positive or an accepted risk and you want it ignored in code, reviewable in version control
• Your .aikido exclude paths are not matching the files you expected
• You need to ignore a specific CVE for one repository and record why

Not for this skill when

• The finding is a real, reachable vulnerability: fix it instead of ignoring it
• You need to choose the narrowest ignore scope (this issue vs by path vs by CVE vs by rule): see the ignore scopes skill in Related skills
• You are ignoring a single pull-request finding via a PR reply, including the 400 feature-disabled error: see the PR ignore skill in Related skills

Steps

1. Decide the scope before you write anything. Ignore the smallest thing that covers the problem: one path or one CVE in this repository beats a broad pattern. Every ignore should carry a reason a reviewer can judge later.

Expected: you know exactly which finding, path, or CVE you are ignoring, and why.

2. Create or edit the .aikido file at the repository root. Add your excluded paths as literal substrings of the full file paths, not glob patterns.

Expected: the file sits at the repo root; each entry is a plain path fragment like a folder name or a generated-file path, with no wildcard characters.

3. To ignore a CVE instead of a path, record the CVE in the same .aikido file together with your reason.

Expected: the Aikido UI shows the CVE as ignored with your reason next to it, so the decision is visible to the whole team.

4. Commit the .aikido file and let Aikido rescan.

Expected: the excluded files no longer appear in secrets, SAST, lockfile, code-quality, or Deep Review results, and the ignored CVE stops being reported for this repository.

5. If an exclude entry did not take effect, check the spelling against the full path first. Matching is string inclusion, so an entry works only if it appears verbatim somewhere in the path Aikido reports; a pattern that looks right as a glob silently matches nothing.

Expected: after correcting the entry to a literal substring, the rescan drops the file.

Variant phrasings

.aikido exclude paths not matching

The troubleshooting form of this query. The cause is almost always a glob or regex habit: Aikido matches by string inclusion, so rewrite the entry as a literal substring of the full path (step 5).

aikido ignore cve

The CVE form: record the CVE in the .aikido file with a reason (step 3). The reason is not optional bookkeeping; it is what the UI shows and what a later reviewer audits.

aikido ignore file

The file itself is the mechanism: one .aikido file at the repository root carries both path exclusions and CVE ignores for that repository.

Root cause

Aikido's code-based ignores are deliberately simple: the .aikido file is parsed as literal configuration, and path matching is substring inclusion over the full file path. There is no glob engine and no regex engine, so patterns imported from other tools (gitignore-style or linter-style) fail silently instead of erroring, which is why excludes so often look correct and do nothing.

Edge cases

• The .aikido file must live at the repository root; one placed in a subfolder is not picked up for the repo-wide scans.
• An ignored CVE with no reason is a future audit problem: write the reason when you add the ignore.
• Broad substrings exclude more than you intend (a short folder name can appear in many paths); use the longest distinctive fragment that still matches.
• Ignoring hides the finding from the listed scan types; it does not change the code, so re-check ignores when dependencies or code layout change.

Tool compatibility

Aikido Security code scanning (secrets, SAST, lockfile, code quality, Deep Review) with .aikido files as documented in the Aikido help pages linked in the evidence.

Related skills

• Aikido ignore scopes: this issue vs by path vs by CVE vs by rule: https://vectle.com/skills/skl_T4dgUYBdk7Go3wyxdsfMhQ
• Ignoring an Aikido PR finding via an @AikidoSec ignore reply, and the 400 feature-disabled error: https://vectle.com/skills/sklGEAo-Z4RPQxQsOsTMCZhQ

Provenance

Built from Aikido's documentation on ignoring via code with .aikido files, linked in the evidence.

Source: Problem: Exclusions in the .aikido file do not match the files you expected. Path matching in .aikido is simple string inclusion: if the configured value appears anywhere in the full file path, the file is excluded. Wildcards and regular expressions are not supported. Place the .aikido file in the repository root. The exclude/paths key hides files from secrets, SAST, lockfile, code-quality and Deep Review scans. The same file can also ignore specific CVEs with a reason, which the Aikido UI then shows next to the ignored CVE.

Verified resolution: Per Aikido docs: use literal path substrings in .aikido (no wildcards or regex) and record CVE ignores with a reason.

Source URL: https://help.aikido.dev/code-scanning/scanning-practices/ignore-via-code-with-aikido-files.md

Not specified by the original author.

TL;DR

Per Aikido docs: prefer the narrowest ignore scope - CVE and rule ignores apply to all repositories.

Steps

1. Per Aikido docs: prefer the narrowest ignore scope - CVE and rule ignores apply to all repositories.

When to use

You are seeing this: Options: Only this issue or issue group (narrowest - note that ignoring a group does not auto-ignore future subissues, which re-open the group); Ignore by path (creates a rule ignoring all current and future file-based issues under a path, e.g. test... Use this skill when you run into "Aikido ignore scopes: this issue vs by path vs by CVE vs by rule".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Problem: You need to silence a finding but are unsure which ignore scope to pick. Options: Only this issue or issue group (narrowest - note that ignoring a group does not auto-ignore future subissues, which re-open the group); Ignore by path (creates a rule ignoring all current and future file-based issues under a path, e.g. test frameworks); Ignore all findings for a CVE (global across every repository); Ignore all findings for a rule (global across every repository, e.g. one SAST rule). CVE and rule ignores are global, so prefer the narrowest scope that fits. The ignore view consolidates auto-ignored and manually ignored issues with their rationale.

Verified resolution: Per Aikido docs: prefer the narrowest ignore scope - CVE and rule ignores apply to all repositories.

Source URL: https://help.aikido.dev/getting-started/core-functionalities/ignore-issues-to-remove-issues-from-main-feed.md

Not specified by the original author.

TL;DR

Per the Aikido workflow notes: ignore PR findings with @AikidoSec ignore: on the finding thread; a 400 means the workspace MCP ignore permission is disabled.

Steps

1. Per the Aikido workflow notes: ignore PR findings with @AikidoSec ignore: on the finding thread; a 400 means the workspace MCP ignore permission is disabled.

When to use

You are seeing this: Reply on that finding comment thread with a message starting "@AikidoSec ignore:" followed by the ignore reason. Use this skill when you run into "Ignoring an Aikido PR finding via an @AikidoSec ignore reply - and the 400 feature-disabled error".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Problem: Aikido flagged a false positive on a pull request. Reply on that finding comment thread with a message starting "@AikidoSec ignore:" followed by the ignore reason. Via the MCP server, call the ignore tool with the issue_id from the feed and the reason. If the MCP call returns "400 - Feature is disabled for this workspace", the workspace MCP ignore permission is off - point an Aikido admin at the MCP permissions settings page to enable it, and fall back to ignoring the issue manually in the UI in the meantime.

Verified resolution: Per the Aikido workflow notes: ignore PR findings with @AikidoSec ignore: on the finding thread; a 400 means the workspace MCP ignore permission is disabled.

Source URL: https://github.com/lifinance/contracts/blob/HEAD/.agents/commands/aikido-address-findings.md