> ## Documentation Index
> Fetch the complete documentation index at: https://docs.octopoda.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Fix a finding with Cursor or Claude Code

> Copy an Octopoda fix prompt from the web app, the CLI or MCP into Cursor or Claude Code, review the change, and scan again to confirm the fix.

Every Octopoda finding comes with a fix prompt: instructions written for an AI coding tool that name the file, explain the issue and describe the change. You paste it into Cursor or Claude Code, review what the tool changes, and scan again to confirm the issue is gone.

## Get the fix prompt

> [tab] Web app
>
> Open the finding. At the top, in **Fix it**, choose **Cursor** or **Claude Code** to get the prompt written for that tool, then select **Copy fix prompt**.
>
> If the finding has a suggested code change, **See the code change** shows it as a diff.

> [tab] CLI
>
> ```bash theme={null}
> octopoda fix F-142
> ```
>
> The CLI prints the finding's severity and title, what is wrong, and the fix prompt. You can pass the key with or without the `F-`, or the finding's full ID.
>
> When you pipe the output, the CLI prints only the prompt, ready for another tool:
>
> ```bash theme={null}
> octopoda fix F-142 | pbcopy
> ```

> [tab] MCP
>
> With the [MCP server](https://docs.octopoda.dev/integrations/mcp.md) connected, ask your AI tool to fix the finding:
>
> ```text theme={null}
> Use Octopoda to get the fix for F-142 and apply it.
> ```
>
> The tool calls `octopoda_get_fix`, which returns what is wrong, why it matters and the fix instructions.

## Apply and confirm the fix

**1. Paste the prompt**

Open the project in Cursor or Claude Code and paste the prompt into a new chat.

**2. Review the change**

Read the diff before you accept it. The prompt says what to change, but your AI tool writes the code, and it can get things wrong. Run your tests.

**3. Scan again**

Push the fix and let the pull request check scan it, or run `octopoda scan`. A finding that the new scan can no longer reproduce does not appear in it.

## When a finding is marked fixed

Octopoda marks a finding **Fixed** automatically when a later full code scan of the same code re-tests it and can no longer reproduce it. The finding page then links to the scan that confirmed the fix. That happens on:

* a code scan of a repository's default branch, started with **New scan** in the web app, for findings in that repository;
* a code scan from the CLI or your AI tool, for findings from earlier scans of the same project folder. Octopoda recognizes the project by the folder's name, so scan from the same folder.

> [!NOTE]
>
> Pull request scans, and scans of other branches, don't mark findings fixed. Merge the fix, then scan the default branch.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.