CodeCureAgent: Automated Java Warning Repair
- CodeCureAgent is an agentic system that automatically classifies, suppresses, or repairs SonarQube static analysis warnings in Java projects using a comprehensive end-to-end workflow.
- It employs a dual sub-agent approach that leverages repository context, AutoGPT, and RepairAgent to perform iterative analysis and validated code modifications.
- The system achieves high plausible-fix rates (96.8%) and outperforms baselines by ensuring builds, warning elimination, and successful test execution.
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Attrah, 25 Apr 2026), CodeCureAgent mutates the repository; unlike repository-level issue resolvers such as CodeR, which target natural-language GitHub issues (Chen et al., 2024), 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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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% (Joos et al., 15 Sep 2025).
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% (Joos et al., 15 Sep 2025).
| 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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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) (Joos et al., 15 Sep 2025).
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 (Joos et al., 15 Sep 2025).
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 (Pinto et al., 10 Apr 2026). CodeR shows that repository-level issue resolution benefits from explicit workflow decomposition into roles such as Manager, Reproducer, Fault Localizer, Editor, and Verifier (Chen et al., 2024). 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++ (Sonwane et al., 2 Feb 2026).
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 (Joos et al., 15 Sep 2025).
