RuboCop pre-commit fails: user cache stores sandbox path, breaks Terminal.app and commits

[caranicole (Cara Cubicciotti)]

Describe the Bug

Summary
After RuboCop is run in Cursor’s environment (e.g. pre-commit or from Cursor’s terminal), RuboCop’s user-level cache (~/.cache/rubocop_cache) stores the path to the inherited gem as a path under cursor-sandbox-cache. Later, RuboCop uses that cached path even when run from Terminal.app (not launched from Cursor), where the sandbox path does not exist, so it fails with “Configuration file not found” for that path. Clearing the RuboCop cache fixes the problem.

Observed Behavior
RuboCop’s user cache ends up containing (or being keyed by) the sandbox path for the gem used in inherit_gem.
Any later RuboCop run (including in Terminal.app) uses that path and fails with “Configuration file not found” for the sandbox path.

Workaround
Clear RuboCop’s user cache, then run RuboCop (or commit) again from Terminal.app:
rm -rf ~/.cache/rubocop_cachecd /path/to/projectbin/rubocop # or: git commit …
After that, RuboCop and pre-commit succeed in Terminal.app.

Technical notes
Project .bundle/config has BUNDLE_PATH: “vendor/bundle”; no global ~/.bundle/config; no BUNDLE_PATH/GEM_PATH/cursor/sandbox in .zshrc or .zprofile.
In Terminal.app, ruby -e “puts ENV[‘BUNDLE_PATH’]” and GEM_PATH are empty; resolving the gem via Bundler returns the correct vendor/bundle path. So the wrong path comes from RuboCop’s use of its cache, not from the current Bundler or Ruby env.

Steps to Reproduce

Open the project in Cursor and run something that runs RuboCop (e.g. git commit so lefthook runs RuboCop, or run bin/rubocop from Cursor’s terminal).
Open Terminal.app on its own (not from Cursor), cd to the project, and run bin/rubocop on any path (or run git commit so pre-commit runs RuboCop).
Observe: RuboCop fails with something like:
Configuration file not found: /private/var/folders/…/T/cursor-sandbox-cache/…/bundle/ruby/3.4.0/gems/-/lib/rubocop/default.yml
even though the file exists at the project’s bundle path (e.g. …/vendor/bundle/ruby/3.4.0/gems/-/lib/rubocop/default.yml).
In Terminal.app, bundle show and a small Ruby script using Bundler to resolve the gem both return the correct vendor/bundle path. No BUNDLE_PATH/GEM_PATH or sandbox paths appear in Gem.path or in the shell.

Expected Behavior

Cursor’s sandbox paths are not written into user-level caches used by tools (e.g. RuboCop’s cache), so the same tools keep working in a normal terminal.
Or RuboCop, when run under Cursor, does not cache absolute paths that refer to Cursor’s sandbox.

Operating System

MacOS

Version Information

Environment
macOS (arm64)
Cursor (version: 2.5.26)
Ruby 3.4.8 (mise)
Project: Rails app using Bundler with vendor/bundle, lefthook pre-commit, RuboCop inheriting from app-config gem (inherit_gem: -config: - lib/rubocop/default.yml)

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the detailed report. It’s really well documented.

This is a known type of issue with how the sandbox handles environment variables. When you run commands in Cursor’s terminal, the sandbox overrides BUNDLE_PATH to point to a temp directory under cursor-sandbox-cache. RuboCop then resolves gem paths through that redirected location and caches the absolute sandbox paths in ~/.cache/rubocop_cache. Once the Cursor session ends, those temp paths no longer exist, so any RuboCop run outside Cursor (like from Terminal.app) fails.

The same problem was already found and fixed for other variables (like GEM_HOME), but BUNDLE_PATH was missed. It controls where Bundler looks for gems, not just where it caches data, so it shouldn’t be redirected. I’ve flagged this with the team. No ETA yet, but your report helps us prioritize it.

Related thread: Shell Tool Injects 30+ Sandbox Cache Environment Variables

Besides clearing the cache rm -rf ~/.cache/rubocop_cache, you can also try switching to the Legacy Terminal Tool in Cursor Settings > Agents > Legacy Terminal Tool. That should bypass the env var injection entirely.

Let me know if you have questions.