---
title: 'CodeCureAgent: Automated Java Warning Repair'
url: https://www.emergentmind.com/topics/codecureagent
type: topic
---

# CodeCureAgent: Automated Java Warning Repair

CodeCureAgent is an agentic system for handling static analysis warnings in Java projects. It is designed to automatically analyze a warning, classify it as a true positive or false positive, suppress false positives, and repair true positives within a single end-to-end workflow. In the reported implementation, warnings come from SonarQube, the agent operates over repository context rather than a single isolated snippet, and candidate changes are accepted only after a three-step approval process consisting of project build, warning disappearance without introducing new warnings, and test-suite execution [2509.11787].

## 1. Scope and task definition

CodeCureAgent addresses a narrower and more operationally specific problem than general automated program repair. Its unit of work is a **static analysis warning**, not an arbitrary bug report, and its primary objective is to decide whether the warning should be fixed or suppressed. This distinction is central because the paper treats static analysis as a mixed stream of actionable issues and false positives. A true positive should generally be repaired, whereas a false positive should often be suppressed rather than “fixed” according to the rule documentation [2509.11787].

The system is evaluated only on **Java** warnings produced by **SonarQube**. Each warning is represented by seven fields: **Repository**, **RuleKey**, **FilePath**, **StartLine**, **RuleName**, **SpecificMessage**, and **RuleType**. The operating assumptions are equally concrete: the target repository must be available at a specific commit, the project must be buildable, tests must be runnable, and SonarQube’s Java suppression mechanisms must be available for the false-positive path [2509.11787].

A common misconception is that CodeCureAgent is simply a warning fixer. The paper explicitly defines it more broadly as a system for **automatic classification and repair of static analysis warnings**. Another misconception is that every warning is actionable. The motivating Lombok example shows why this is not so: SonarQube may flag a private field as unused even though the field is used indirectly through Lombok-generated methods, making deletion harmful rather than corrective [2509.11787].

In this respect, CodeCureAgent occupies a distinct position in the agentic software-engineering landscape. Unlike diagnosis-only systems such as Code Broker, which stop at assessment and recommendation [2604.23088], CodeCureAgent mutates the repository; unlike repository-level issue resolvers such as CodeR, which target natural-language GitHub issues [2406.01304], it begins from a static-analysis warning and uses that warning as the organizing object of diagnosis, suppression, and repair.

## 2. Inputs, tooling, and agent environment

The system is implemented on top of **AutoGPT** and **RepairAgent**, and uses **GPT-4.1 mini**, version **2025-04-14**, as its underlying model. The reported pricing at the time of writing is **$0.4 / million input tokens** and **$1.6 / million output tokens**. Execution ran in a Docker container on a VM with an **Intel Xeon CPU at 2.1 GHz**, **16 vCPUs**, and **32 GB RAM** [2509.11787].

The tool environment is deliberately repository-aware. Both the classification and repair stages can use **Read documentation**, **Read lines**, **Find references**, **Find definition**, and **Search patterns**. The repair stage adds **Formulate plan**, **Write fix**, and **Goals accomplished**. The classifier additionally has **Answer classification questions** and **Give final verdict**. For false positives, the suppression path is narrower: **Read lines**, **Write fix**, and **Goals accomplished** [2509.11787].

The prompt structure for the classification sub-agent is explicit at a high level. Each cycle includes six sections: **Role and objectives**, **Constraints**, **Available tools**, **Input warning**, **Agent history**, and **Response format definition**. Outputs are parsed as tool calls in a predefined JSON-like format, and if parsing fails, the parsing error is fed back into history. Tool outputs are truncated to the first **125K tokens** before reinsertion into history [2509.11787].

The system also encodes operational budgets. The maximum number of cycles is **20** for the classification sub-agent and **40** for the repair sub-agent. Near the end of the repair budget—specifically when **five or fewer cycles remain**—the prompt is augmented with a message urging the model to produce a fix [2509.11787].

## 3. Agent workflow and internal mechanics

The end-to-end pipeline has four main parts: a preparation stage, a classification sub-agent, a repair sub-agent, and a change approver. The preparation stage runs static analysis on the target project and extracts warnings and metadata. Then, warnings are processed one at a time [2509.11787].

The classification sub-agent is the decisive front end. It does not merely label a warning; it is required to answer three guiding questions: whether the warning is **correctly raised** and the rule applies in the concrete case, whether the developer may have **intentionally** violated the rule for design or functional reasons, and whether the warning can be **fixed without breaking existing functionality**. The agent answers each question with yes/no plus explanation grounded in gathered evidence, and then emits a final **TP** or **FP** verdict with rationale [2509.11787].

If the warning is classified as a true positive, the repair sub-agent attempts a semantic fix. If the warning is classified as a false positive, the system generates a suppression instead. Suppression relies on SonarQube’s Java mechanisms: inline `//NOSONAR` comments or `@SuppressWarnings({"java:S..."})`, with the prompt instructing the model to prefer `//NOSONAR` because broader annotations can hide future issues [2509.11787].

For true positives, CodeCureAgent represents edits in a structured JSON format with per-file **insertions** and **deletions**. This supports multiple edits in one file, edits across multiple files, and iterative refinement across attempts. The paper’s shortened S1104 example shows the system changing a public field to private, adding getters and setters, inserting `@SerializedName("_number")`, and updating both references and tests in other files [2509.11787].

This multi-file capability is one of the system’s important differentiators. Earlier warning-repair approaches discussed in the paper are more rigid: **Sorald** encodes hand-crafted transformations for only **30 rules**, while **CORE** is LLM-based but limited to **single-file** operation. CodeCureAgent’s repair agent instead uses repository tools to inspect surrounding code, search references, formulate a plan, write structured edits, and react to compiler, analyzer, and test feedback in later iterations [2509.11787].

## 4. Validation logic and the meaning of a “plausible fix”

The most consequential component is the **change approver**, which defines acceptance. A patch is approved only if it passes three checks in sequence: **project build**, **warning disappearance without introducing new warnings**, and **test-suite execution** [2509.11787].

The build step rejects patches that are syntactically or type-wise invalid. If compilation fails, the system extracts relevant compilation errors, reports file path and line number, includes the failing code line, and presents a diff-like view between original and modified code. This feedback is then returned to the repair loop [2509.11787].

The second step reruns static analysis on the modified project. Approval requires that the **target warning** disappear and that **no new warnings** be introduced. Because edits shift line numbers, the system maps warning locations between original and modified versions by tracking line changes in modified files. The paper states that this detection is **sound** in the sense that it always detects newly introduced warnings, although it may over-approximate in corner cases such as deleting and reinserting warning-carrying lines elsewhere [2509.11787].

The third step runs the project’s tests. If all tests pass, the patch is accepted as **plausible**. If tests fail, stack-trace parts outside the target project are removed and the failure report is fed back to the repair agent. The paper explicitly notes that the system may then either revise the fix or adjust a faulty test if the warning repair exposed an overly strict assumption in the test suite [2509.11787].

A second common misconception is that “plausible” and “correct” are interchangeable. The paper rejects that equivalence. **Plausible** means the patch builds, removes the warning without introducing new warnings, and passes tests. **Correct** is established separately through manual semantic inspection on a subset of cases [2509.11787].

## 5. Evaluation and empirical results

The evaluation uses a benchmark of **1,000 SonarQube warnings** from **106 Java projects** covering **291 distinct rules**. The benchmark is built from the Sorald dataset by starting with **161 projects**, excluding **4 projects** used during development and **25 projects** that could not be built successfully with Maven or had failing tests, leaving **132 Java projects**. Running SonarQube with the default **SonarWay** profile produced **95,083 warnings** across **291 distinct rules**. The final benchmark consists of **one warning per occurring rule** (**291 warnings**) plus **709 additional randomly sampled warnings** [2509.11787].

On the full benchmark, CodeCureAgent classifies **696** warnings as true positives and **304** as false positives, and produces **plausible fixes for 968 warnings**, corresponding to a **96.8%** plausible-fix rate. Among true positives, plausible-fix rate is **665 / 696 = 95.6%**; among false positives, it is **303 / 304 = 99.7%** [2509.11787].

On the manually inspected **291-warning** one-per-rule subset, the system achieves **267 / 291 = 91.8%** correct classification, **259 / 291 = 89.0%** plausible fixes, and **251 / 291 = 86.3%** correct fixes. The classwise breakdown is asymmetric: for true positives, correct classification is **186 / 191 = 97.4%** and correct fixes are **170 / 191 = 89.0%**; for false positives, correct classification, plausible fixes, and correct fixes are all **81 / 100 = 81.0%** [2509.11787].

| Metric | Result | Scope |
|---|---:|---|
| Plausible-fix rate | 96.8% | 1,000 warnings |
| Correct classification | 91.8% | 291 inspected warnings |
| Correct-fix rate | 86.3% | 291 inspected warnings |
| Average cost | 2.9 cents per warning | Full run |
| Mean runtime | 4.4 minutes | Per warning |

Against baselines, the gap is large. On all **1,000** warnings, **Sorald** creates fixes for **55** warnings and has **43 plausible fixes (4.3%)**, while **CORE** creates fixes for **926 (92.6%)** but only **676 (67.6%)** are plausible under the paper’s validation. The paper reports that CodeCureAgent outperforms prior methods by **30.7%** and **29.2%** in plausible-fix rate, respectively [2509.11787].

The fixes are not exclusively trivial. Among the **1,000** generated fixes, **52.0%** are single-line, **44.4%** are multi-line, and **3.6%** are multi-file. Among plausible fixes, single-line plausibility is **99.4%**, multi-line plausibility is **95.5%**, and multi-file plausibility is **75.0%**. The system therefore produces **424** plausible fixes modifying multiple lines and **27** plausible fixes affecting multiple files [2509.11787].

Runtime and cost are modest but non-negligible. The mean time is **4.4 minutes**, the median **2.8 minutes**, average consumption is **139K tokens per warning**, and average LLM cost is **2.9 cents USD per warning**. Runtime is dominated by validation: **41.1%** of time is spent on build, test, and static-analysis checks, and **39.2%** on LLM queries [2509.11787].

## 6. Limitations, misconceptions, and broader significance

The paper identifies several failure modes. In the manually inspected subset there are **24 misclassifications (8.2%)**, of which **19** are warnings wrongly classified as false positives. The causes are distributed across **LLM hallucination (11/24)**, **insufficient context (11/24)**—including imprecise rule documentation in **9/24** and shallow gathered project context in **2/24**—and **other reasons (2/24)** involving conventions the LLM does not agree with [2509.11787].

Repair failures are also characterized. The repair sub-agent fails to plausibly fix **32** warnings, and among manually inspected plausible fixes there are **8** that remain incorrect. The dominant cause is **inability to fix incorrect code modifications that break code (26/32)**; other causes are **addressing multiple warnings at once (4/32)** and **tool limitations**, specifically the lack of support for creating, renaming, or deleting files (**2/32**) [2509.11787].

Several boundary conditions follow. The study covers only **Java** and **SonarQube**, excludes projects with broken builds or failing tests, reports no inter-rater agreement statistics for manual inspection, and relies on **GPT-4.1 mini** rather than demonstrating model-agnostic behavior. The paper therefore supports strong claims about this specific setting, but not yet about full language- or analyzer-independence [2509.11787].

Within the broader research trajectory, CodeCureAgent can be read as a warning-centric repair agent that combines repository tools, iterative reasoning, and aggressive validation. Adjacent work highlights complementary design pressures. CodeGen argues that production readiness depends at least as much on tool design, safety enforcement, state handling, and trust calibration as on model quality [2604.09805]. CodeR shows that repository-level issue resolution benefits from explicit workflow decomposition into roles such as Manager, Reproducer, Fault Localizer, Editor, and Verifier [2406.01304]. A plausible implication is that future variants of CodeCureAgent could be evaluated not only on warning repair but also on broader software-engineering task families such as those collected in OmniCode, which spans bug fixing, test generation, review-response fixing, and style fixing across Python, Java, and C++ [2602.02262].

Taken together, CodeCureAgent’s main contribution is not a new static analysis algorithm, but an end-to-end operationalization of warning handling as an agentic workflow: classify first, then suppress false positives or repair true positives, and finally validate with build, re-analysis, and tests. That combination is what turns static-analysis warnings from a passive backlog into an executable remediation pipeline [2509.11787].

Source: https://www.emergentmind.com/topics/codecureagent