ruby-lsp not picking up changes in .rubocop-todo.yml

[AlexVPopov]

Description

Ruby LSP Information

Ruby LSP Information

VS Code Version

1.96.2 (that's Cursor)

Ruby LSP Extension Version

0.9.28

Ruby LSP Server Version

0.24.1

Ruby LSP Add-ons

• Ruby LSP Rails

Ruby Version

3.1.2

Ruby Version Manager

rbenv

Installed Extensions

Click to expand

• copilot (1.270.0)
• copilot-chat (0.23.2)
• cucumberautocomplete (3.0.5)
• debugpy (2025.8.0)
• elixir-ls (0.28.0)
• endwise (1.5.1)
• gitlens (17.1.1)
• go (0.46.1)
• makefile-tools (0.12.17)
• material-icon-theme (5.23.0)
• prettier-sql-vscode (1.6.0)
• procfile (1.1.7)
• python (2025.6.1)
• rainbow-csv (3.19.0)
• remote-containers (0.394.0)
• remote-wsl (0.81.8)
• ruby-extensions-pack (0.1.13)
• ruby-lsp (0.9.28)
• sorbet-vscode-extension (0.3.42)
• sublime-keybindings (4.1.10)
• terraform (2.34.4)
• vscode-codeowners (1.1.1)
• vscode-containers (2.0.3)
• vscode-dash (2.4.0)
• vscode-docker (2.0.0)
• vscode-fileutils (3.10.3)
• vscode-github-actions (0.27.2)
• vscode-graphql (0.13.2)
• vscode-graphql-syntax (1.3.8)
• vscode-json-validate (1.5.0)
• vscode-pylance (2024.8.1)
• vscode-todo-highlight (1.0.5)
• vscode-yaml (1.18.0)

Ruby LSP Settings

Click to expand

Workspace

{}

User

{
  "enabledFeatures": {
    "codeActions": true,
    "diagnostics": true,
    "documentHighlights": true,
    "documentLink": true,
    "documentSymbols": true,
    "foldingRanges": true,
    "formatting": true,
    "hover": true,
    "inlayHint": true,
    "onTypeFormatting": true,
    "selectionRanges": true,
    "semanticHighlighting": true,
    "completion": true,
    "codeLens": true,
    "definition": true,
    "workspaceSymbol": true,
    "signatureHelp": true,
    "typeHierarchy": true
  },
  "featuresConfiguration": {},
  "addonSettings": {},
  "rubyVersionManager": {
    "identifier": "auto"
  },
  "customRubyCommand": "",
  "formatter": "auto",
  "linters": null,
  "bundleGemfile": "",
  "testTimeout": 30,
  "branch": "",
  "pullDiagnosticsOn": "both",
  "useBundlerCompose": false,
  "bypassTypechecker": false,
  "rubyExecutablePath": "",
  "indexing": {},
  "erbSupport": true,
  "featureFlags": {},
  "sigOpacityLevel": "1"
}

Reproduction steps

Hey folks, I'm not sure if that's a bug, maybe that's how it's supposed to work. If so, please, disregard.

I have a huge .rubocop_todo.yml, which is inherited in my .rubocop.yml Let's say it has:

Style/MethodCallWithArgsParentheses:
  Enabled: false

Logically, in this snippet:

  def foo
    my_method "test"
  end

it doesn't underline anything. Now, let's say I update the .rubocop_todo.yml to:

Style/MethodCallWithArgsParentheses:
  Enabled: true

This change doesn't automatically get picked up by ruby-lsp. I still see no underlining of my_method "test". Only after I manually restart the ruby-lsp server, would it get underlined.

Could you let me know if this is by design? Thank you!

[AlexVPopov]

O.K., I tested this by repeating the same experiment, this time however enabling/disabling the cop not in .rubocop_todo.yml, but in .rubocop.yml. With .rubocop.yml it works as expected (as it has probably been implemented by #2982). In that case, does it make sense to change the pattern to also catch changes in:

• .rubocop_todo.yml;
• .rubocop.yml files located in other directories.

Maybe something like /^(\.\/)?(.+\/)?\.rubocop(_todo)?\.yml$/?

[vinistock]

Thanks for the report! For performance reasons, we only parse RuboCop configurations once, so .rubocop.yml files in nested directories is currently not used. We'd need a collection of different runners for every configuration file and that ends up accounting for a lot of complexity.

That said, we should definitely listen for changes in the todo file and update the RuboCop runner like we do for .rubocop.yml. It should just be a matter of enhancing this glob.

[github-actions]

This issue is being marked as stale because there was no activity in the last 2 months

[github-actions]

This issue is being marked as stale because there was no activity in the last 2 months

[vinistock]

@AlexVPopov are you interested in getting #3625 merged? If not, I can pick this up.

[AlexVPopov]

Hey @vinistock, I'm sorry for the radio silence on this one. It's on my to do list, but I'm not sure, when I'll get back to it. If you want to and have the capacity to take a stab at it, by all means - please do.