RubyMine RuboCop Inspection: Local Feedback, Not a Gate

The problem

RubyMine includes a built-in RuboCop inspection that underlines style violations in the editor and offers quick-fixes. RuboCop is a Ruby static-analysis tool, often called a linter, that checks source code against a style guide without running it. The risk is assuming that a clean editor means the code is clean.

RubyMine runs RuboCop using the project's local Ruby SDK and Bundler gemset. A gemset is the collection of gems Bundler installs for a project. If the IDE resolves a different RuboCop version than CI, or if a developer disables the inspection locally, offenses can reach the repository undetected.

There is also a trust boundary to understand before enabling the inspection. RuboCop loads cops, requires, and plugins from the gems in the project's gemset. A compromised or malicious gem can execute arbitrary code during an inspection, so the IDE integration should not be treated as sandboxed or read-only.

Requirements

• Every developer sees the same RuboCop rules in the IDE as in CI.
• Inspection failures are visible and actionable, not silent.
• No arbitrary code from dependencies runs unintentionally during local editing.
• The design works with the team's existing Ruby SDK, including Docker or WSL interpreters if used.

Smallest suitable design

Commit a .rubocop.yml configuration file to the project root. RubyMine reads standard RuboCop configuration files, including inheritance and gem-provided configs; it does not maintain a separate rule set. Pin RuboCop in the Gemfile so all developers and CI use the same minor line:

# Pin to the RuboCop minor line used by CI.
gem 'rubocop', '~> MAJOR.MINOR'

Enable the RuboCop inspection in RubyMine, but treat it as local feedback only. In standard RubyMine installations, open the IDE settings, navigate to Editor > Inspections, find Ruby > RuboCop, and confirm the inspection is enabled with a severity that makes violations visible. Menu paths vary by IDE version, so verify the exact location in your installation.

Trust and data boundaries

The trust boundary is the local gemset. When RubyMine invokes RuboCop, it executes cops and any requires or plugins loaded by the configuration. That code runs with the same permissions as the user running the IDE. A malicious gem in Gemfile.lock can therefore run arbitrary code during an inspection. Remote interpreters, Docker SDKs, or WSL can change which RuboCop executable runs and where configuration files are resolved, so the boundary moves with the SDK.

The data boundary is the project configuration, not IDE-only settings. Do not store the authoritative rule set inside RubyMine's internal configuration. Store it in .rubocop.yml and let both the IDE and CI read the same file.

Operational checks

1. Open Settings/Preferences > Languages & Frameworks > Ruby SDK and Gems. Confirm the Ruby SDK and gem path resolve to the intended Bundler environment.
2. Open Editor > Inspections > Ruby > RuboCop. Confirm the inspection is enabled and severity is set.
3. Run Code > Inspect Code on a module or the whole project. Review RuboCop results in the inspection tool window.
4. Introduce a deliberate style offense in a Ruby file and confirm it appears as an editor highlight and in the inspection results. Remove the offense after verifying.
5. Run bundle exec rubocop --version in the project terminal and compare the version with CI. The terminal can be RubyMine's embedded terminal or a system terminal; normal user permissions are sufficient. Risk: do not run rubocop --auto-correct on files you have not reviewed, because it can modify multiple files at once.

Failure modes and diagnostics

Symptom	Likely cause	Check
No RuboCop highlights in the editor	Inspection disabled, wrong SDK, or missing RuboCop gem	Verify inspection state in Editor > Inspections and SDK path in Ruby SDK and Gems
Inspection errors in the Events tool window	Invalid YAML in .rubocop.yml or incompatible RuboCop version	Run bundle exec rubocop from the command line to reproduce
Different results between IDE and CI	Configuration drift or different RuboCop gem versions	Compare bundle exec rubocop --version output and .rubocop.yml contents
Silent no-highlighting on large projects	Performance limits or inspection scope exclusions	Run Code > Inspect Code on a specific directory and review the scope

The Events tool window surfaces RuboCop execution errors that do not appear as editor highlights. Check it when the inspection appears enabled but produces no results.

Conditions that would change the design

• Team-wide enforced config: If the team must enforce a single style, move enforcement to CI or a pre-commit hook. A pre-commit hook is a script that runs before a commit is finalized and can block commits with RuboCop offenses. Do not rely on IDE settings alone.
• CI parity requirements: If CI runs RuboCop with --fail-level or specific formatters, replicate those flags in the local check so local and CI results match.
• Large monorepo performance: Running RuboCop on every file save can slow the IDE. Limit the inspection scope to changed files or run it on demand instead of continuously.
• Unsafe cops enabled: Some RuboCop cops can automatically rewrite code in ways that change behavior. Review auto-correct changes before committing, and consider disabling unsafe cops in .rubocop.yml.

Limitations and verification

This draft describes well-established RubyMine RuboCop behavior, but exact menu paths, inspection names, and default severities depend on the RubyMine and RuboCop gem versions in use. RubyMine RuboCop behavior depends on both IDE version and installed RuboCop gem version; older gems may lack cops the IDE expects. Treat this as a draft for human review until verified against your installed versions.

Practical verification: after applying the design, open a Ruby file with a known style offense, confirm the highlight appears, run bundle exec rubocop from the command line, and confirm CI passes or fails on the same rule set. If the three results disagree, fix the configuration drift before relying on the IDE inspection.