Inspection results mismatch in IntelliJ IDEA vs. inspectCode CLI

Question

When running code inspections locally in IntelliJ IDEA, the output often differs from the results produced by the standalone inspectCode command‑line tool. The local IDE uses the project’s .idea configuration and the current inspection profile, while the CLI relies on the supplied config.xml and the environment’s classpath. This inconsistency can lead to false positives or missed warnings in continuous‑integration pipelines.
The goal is to achieve a deterministic, environment‑agnostic inspection outcome. However, the following uncertainties remain:

Do the IDE and CLI resolve inspection profiles identically when the same profile file is used?
Is there a difference in plugin or language‑support version handling between the two executables?
How does the classpath resolution affect which inspections are applied, especially for projects with multiple modules?

What specific factors cause the discrepancy in inspection results between the local IDE and the inspectCode CLI tool, and how can they be aligned for consistent CI/CD validation?

Tasadduq Burney · Answer

Direct answerAssumption: inspectCode is the JetBrains IntelliJ command-line inspection tool, and the IDE and CLI are from the same major version family. The mismatch is usually caused by different inputs to the same inspection engine, not by different inspection logic. IntelliJ IDEA applies the active profile from .idea/inspectionProfiles, project-specific severity and suppression overrides, the open project module graph, SDK, language level, roots, exclusions, encoding, and loaded plugins. inspectCode applies the profile or config passed to it, the project root and classpath it resolves, and the plugins available in that headless installation. Missing dependencies can make symbol-resolving inspections report unresolved-reference false positives or skip downstream checks, and scope differences can make a whole-project CLI run look noisier than a changed-file IDE run.Established factors and alignment stepsFactorEffectAlignment actionInspection profileDifferent enabled rules, severities, or suppressionsExport the active IDE profile to XML, commit it, and pass it explicitly to inspectCodeScopeIDE may inspect changed files; CLI may inspect whole projectRun a full-project IDE inspection with the same profile and scope as CLIJDK and language levelAPI and language-level inspections change with runtimeUse the same project SDK/JDK and language level in IDE and CIClasspath and modulesMissing modules, generated sources, test roots, or exclusions change symbol resolutionMatch .idea/.iml module dependencies, source/test/resource roots, and exclusionsPlugins and language supportKotlin, JavaScript, database, or framework inspections may be absent headlessEnable the same plugin set or restrict comparison to inspections present in bothEncodingFile encoding affects inspections that read non-ASCII contentSet the same project and file encoding in CISteps for this caseIn IntelliJ IDEA, open Inspections, export the active profile to XML, for example ci/inspection-profile.xml, and commit it. Do not rely on workspace-only overrides in .idea/workspace.xml.Run inspectCode with the same project root and profile. Example: ./inspectCode.sh --profile ci/inspection-profile.xml --output ci/inspect-code-results.xml --format xml [project-root]. Use inspectCode.bat on Windows. Verify flags with inspectCode --help because option names vary by JetBrains version.Run a full-project inspection in the IDE using the same profile and scope, then export IDE XML.Normalize both XML files by removing timestamps, absolute paths, and profile metadata; compare by rule, file, line or offset, message, and severity.Pin IDE build, inspectCode version, JDK, profile XML, and module configuration in CI; rerun on a clean checkout to confirm deterministic output.Version-sensitive verificationList enabled inspections and plugin versions in both environments if results still differ. CLI flags and plugin-loading behavior are version-sensitive, so check them against your installed inspectCode rather than assuming they match the desktop IDE.Missing diagnostic detailAre the same bundled and third-party plugins enabled in the headless inspectCode run as in the desktop IDE? This changes the recommendation because a different plugin set changes which rules exist, so you may need to align plugins or exclude plugin-specific rules from the comparison.

Inspection results mismatch in IntelliJ IDEA vs. inspectCode CLI

1 answer

Direct answer

Established factors and alignment steps

Steps for this case

Version-sensitive verification

Missing diagnostic detail

Your perspective belongs here.

0 question comments

Factor	Effect	Alignment action
Inspection profile	Different enabled rules, severities, or suppressions	Export the active IDE profile to XML, commit it, and pass it explicitly to inspectCode
Scope	IDE may inspect changed files; CLI may inspect whole project	Run a full-project IDE inspection with the same profile and scope as CLI
JDK and language level	API and language-level inspections change with runtime	Use the same project SDK/JDK and language level in IDE and CI
Classpath and modules	Missing modules, generated sources, test roots, or exclusions change symbol resolution	Match .idea/.iml module dependencies, source/test/resource roots, and exclusions
Plugins and language support	Kotlin, JavaScript, database, or framework inspections may be absent headless	Enable the same plugin set or restrict comparison to inspections present in both
Encoding	File encoding affects inspections that read non-ASCII content	Set the same project and file encoding in CI