Scan a local repository with the Codex Security plugin, review the evidence behind each finding, and decide what needs investigation or a fix. Start with one repository or service so you can review its coverage before expanding the scan.

Before you start

Open a local repository that you own or have permission to assess in Codex. Install and enable the Codex Security plugin, and confirm that your account and workspace have the required security access.

Start with a standard scan of the repository or one service. It runs the scan workflow once and gives you findings, supporting evidence, and coverage to review before deciding what to fix. For a large monorepo, choose one folder with a clear service or product boundary.

Use the starter prompt in that repository’s Codex project, replacing the path with your intended scope. To configure the same scan in the Security sidebar, follow Run your first scan. Choose one way to start the scan.

Run your first scan

For an application that keeps each customer’s data in a separate workspace, you could add this security context:

Users must only retrieve documents from workspaces they belong to.
Review whether a user can supply another workspace's identifier and
retrieve its private documents. Check where workspace membership is
enforced, including background jobs and direct API calls.

Follow the scan and check coverage

Codex identifies the application’s assets and security boundaries, reviews code for candidate vulnerabilities, validates candidates, and assesses their impact before producing the report. Select View activity to inspect the underlying Codex task, and wait for the scan to finish.

Open the completed scan and confirm the target and revision. Review coverage, including skipped or deferred areas, before reading the findings. A completed scan can contain vulnerabilities; an empty findings list with incomplete coverage does not establish that the code is secure.

If the scan stops or leaves gaps, record those areas for follow-up. Scan time and resource use depend on the selected code and the validation work required.

Understand a finding

Select a finding and open Summary. Review these questions together:

• What can an attacker do? Read the affected code, root cause, and reported impact.
• How can they reach it? Follow the attack path from attacker-controlled input to the sensitive operation, including any existing safeguards.
• What did the scan demonstrate? Read the validation evidence, severity rationale, and remaining uncertainty. A severity label alone is not enough to accept a finding.

In this example, a request supplies a workspace identifier that reaches private-document retrieval without a membership check. To assess a similar finding in your code, inspect whether another control enforces membership and whether the validation demonstrates access across workspaces.

For help interpreting a finding, open a chat in the same repository project and include the finding’s title, affected code, and evidence:

Choose the next action

Keep a short record of each reviewed finding: the scanned revision, affected code, evidence, remaining uncertainty, and responsible team. Choose the next action based on that evidence:

• Needs a fix: Select one accepted finding and continue to Fix a finding from your security scan.
• Needs investigation: Keep it open and identify the missing check or information before making a remediation decision.
• Does not need a fix: Record the supporting evidence and your triage decision. Closing a finding records that decision; it does not change code.

Your result is a reviewed set of findings and coverage gaps, with a next action for each. If you need a more thorough assessment, use Run a deep security scan. To assess a specific pull request or diff, use Scan code changes for security.