RubyGems' gem cleanup removes old versions of gems: for each gem in the current Ruby's gem folder, it keeps the newest version and removes older ones no other installed gem needs. It never removes the newest version of anything, never touches your other Rubies' gems, and leaves alone the gems that come with Ruby itself.
On most Macs, old gem versions aren't where Ruby's space goes. Whole Ruby versions are. A version manager such as rbenv, rvm, chruby, asdf or mise keeps every Ruby you've installed, each with its own complete set of gems, and none of them removes an old Ruby until you ask.
So the order that frees the most is: remove the Ruby versions no project uses, let RubyGems clean up old gem versions in the ones you keep, then look at Bundler's folders in finished projects. Each tool removes its own versions, and rbenv's and chruby's can also go to the Trash in Finder.
This post goes through where Ruby and its gems live on a Mac, what each cleanup removes and keeps, what every version manager leaves behind, and the Ruby you may have without ever writing Ruby.
Where Ruby and gems live on a Mac
A Mac can have several Rubies at once, and each one keeps its gems in its own folder. Knowing which Ruby put a folder there tells you which tool should remove it.
| What | Where it is | Who manages it | Level |
|---|---|---|---|
| Ruby versions from rbenv | ~/.rbenv/versions | rbenv and ruby-build | Review first |
| Ruby versions from rvm | ~/.rvm/rubies, gems in ~/.rvm/gems | rvm | Not in the catalog |
| Ruby versions for chruby | ~/.rubies, gems in ~/.gem/ruby | ruby-install, chruby | Not in the catalog |
| Tool versions from asdf and mise | ~/.asdf/installs, ~/.local/share/mise/installs | asdf, mise | Review first |
| Homebrew's Ruby and its gems | /opt/homebrew/Cellar/ruby, /opt/homebrew/lib/ruby/gems | Homebrew, RubyGems | Review first |
| macOS's own Ruby | /usr/bin/ruby and the system's Ruby framework | macOS | Leave alone |
| A project's gems | vendor/bundle inside the project | Bundler | Usually safe |
| Bundler's shared cache | ~/.bundle/cache | Bundler | Safe |
Most of these folders start with a dot, which is why Finder doesn't show them in your home folder. They're ordinary folders all the same.
How do you open these folders in Finder?
Use Go to Folder, which opens any folder by its path, hidden or not.
- In Finder, choose Go › Go to Folder, or press Shift-Command-G.
- Type the path, such as
~/. The tilde stands for your home folder..rbenv/ versions - Press Return.
To see hidden folders in your home folder instead, press Shift-Command-Period in a Finder window, and again to hide them.
How do you see how big each version is?
Open the folder that holds the versions, such as ~/, and choose View › as List. Then choose View › Show View Options, select Calculate all sizes, and click the Size column heading to put the largest first.
Each folder is one complete Ruby: the language, its standard library, its documentation and every gem installed while that version was in use. A version that ran a large Rails app is usually much bigger than one you installed to try something.
Where does Ruby show up in Storage settings?
Mostly in System Data. Storage settings, in System Settings › General › Storage, has no category for Ruby, so version managers' folders and gem caches in your home folder count as System Data along with everything else it can't name.
Folders inside your projects are different. A project's vendor/bundle sits with your own files, so it's usually counted under Documents. macOS's own Ruby is part of the system and counts in the macOS category.
What gem cleanup removes, and the old versions it keeps
RubyGems is the package manager that comes with Ruby, and its cleanup command is the one tool that removes old gem versions. It's careful by design, which also explains why it often frees less than you'd expect.
What counts as an old version?
For each gem name, RubyGems looks at every installed version and treats the highest as the one to keep. Every lower version of the same gem is a candidate for removal.
A gem with only one version installed is never touched, however old that version is and however long it's been since you used it. Cleanup is about duplicates, not about gems you don't use.
Why does gem cleanup leave some old versions?
RubyGems' own code skips a candidate for four reasons:
- Another installed gem needs it. If something depends on exactly that older version, cleanup leaves it, and by default it counts development dependencies too.
- It's a default gem. Default gems are part of Ruby itself, and cleanup skips them without asking.
- It's in another gem folder. Cleanup only removes gems from the Ruby's main gem folder, or from your personal one when you ask for that instead.
- You named other gems. Given gem names, cleanup only looks at those.
When it cleans everything, RubyGems repeats the pass until nothing more changes, so removing one old version can free another that only it needed.
Does gem cleanup know about your projects?
No. It checks what installed gems depend on, not what your projects' Gemfile.lock files ask for. Bundler, which installs a project's gems, puts them in the same gem folder by default, so two projects can each have their own version of the same gem there.
If one project locks an older version of a gem and another uses a newer one, cleanup removes the older version. The first project then stops at its next start, until Bundler installs that version again. Nothing is lost, but it costs a download and, for gems with native extensions, a rebuild.
Does gem cleanup clean every Ruby?
No. It cleans the gem folder of the Ruby that's running it. Under a version manager, that's whichever version is selected in the folder you're in, so each version has to be cleaned on its own.
Old gem versions for a Ruby you no longer use don't need cleaning at all. Removing that Ruby removes its gems with it.
Cleanup, uninstall and Bundler's clean: what's the difference?
Ruby's tools have several commands that free space, and each removes something different. None of them has an app or a button.
| Command | What it removes | What it never removes |
|---|---|---|
| RubyGems' cleanup | Older versions of gems that nothing installed depends on | The newest version of each gem, default gems, other Rubies' gems |
| RubyGems' uninstall | One gem, or chosen versions of it, after asking if something depends on it | Gems in other Rubies |
| Bundler's clean | Gems in a project's own gem folder that its Gemfile.lock no longer lists | Anything, without a project folder set, unless forced |
| Bundler's clean, forced | Every gem in the shared folder that this one project doesn't use | Nothing else: it's the risky one |
| rbenv's uninstall | One Ruby version and every gem installed for it | Other versions |
What these commands remove doesn't go to the Trash: it's deleted straight away. Moving a folder to the Trash in Finder is the route you can undo, where Finder is a supported route at all.
What happens to the .gem files?
Every gem folder has a cache folder of .gem files, the packages each gem was installed from. RubyGems keeps them so it can restore an installed gem to its original state, and it downloads the package again if one is missing.
Uninstalling a gem, by hand or through cleanup, removes its .gem file along with it. So the cache shrinks with the gems; you don't need to clear it separately.
Old Ruby versions: the bigger win
Version managers install each Ruby you ask for into a folder of its own, and keep it. Upgrading a project to a new Ruby installs the new version beside the old one; nothing removes the old one for you.
How do you tell which versions your projects still use?
Most Ruby projects name their version in a file called .ruby-version at the top of the project folder. rbenv, chruby and rvm read it. asdf and mise read it once a setting turns that on; asdf's own file is .tool-versions.
Open each project you still work on and look in that file, with hidden files shown. Make a short list of the versions that appear. Any installed version not on the list, and not your default, is a candidate for removal.
A Gemfile can also name a Ruby version on its own line. If a project has no version file, look there before deciding.
Removing rbenv versions
rbenv keeps each version in ~/, one folder per version, with that version's gems inside it. Its documentation says plainly that versions accumulate there as time goes on.
rbenv's README gives two ways to remove one: delete the version's folder, or use the uninstall command that ruby-build, its install plug-in, adds. In Finder, the first looks like this:
- Choose Go › Go to Folder, type
~/and press Return..rbenv/ versions - Select the folder of a version no project uses, such as
3.1.6. - Choose File › Move to Trash.
- Empty the Trash once you're sure nothing needs it.
Move only a version's folder, never the versions folder itself or the rest of ~/, which holds rbenv's own shims and plug-ins.
What happens after you remove an rbenv version?
That Ruby and its gems are gone. A project whose .ruby-version names it stops with an error saying the version isn't installed, until you install it again, which builds Ruby from source again.
rbenv's own uninstall also refreshes rbenv's shims, the small launcher files for each command. After a removal in Finder, a shim for a command only that version had can stay until rbenv next refreshes them. Running it just reports that the command isn't found.
Removing rvm Rubies
rvm keeps Rubies in ~/, their gems in ~/, sources it compiled in ~/ and downloads in ~/. Because one Ruby is spread across several folders, rvm is the right tool to remove it.
rvm's documentation describes two commands. Its remove command, which it calls the preferred way, takes out the Ruby, its source files, its aliases and wrappers, and optionally its gemsets and downloaded archive. Its uninstall command only removes the Ruby's folder in ~/ and leaves everything else.
So a Ruby removed with uninstall, or by hand in Finder, can leave its gemsets and sources behind. rvm also has an implode command that removes every Ruby it manages and everything in ~/.
chruby and ruby-install: the gems stay behind
chruby only switches between Rubies; it doesn't install them. Its usual partner, ruby-install, puts each Ruby in ~/, and chruby also finds Rubies in /.
Gems are kept apart from the Rubies. chruby's README says gems you install go into ~/, in a folder named after the exact Ruby version. Removing a Ruby from ~/ leaves its gem folder behind, and a patch upgrade such as 3.3.4 to 3.3.5 starts a new, empty one.
ruby-install has no uninstall command. To remove a Ruby, move its folder in ~/ to the Trash in Finder, then the matching folder in ~/ once nothing uses that version.
Does ruby-install keep the source code?
Yes, unless you asked it not to. Its script keeps the downloaded archive and the unpacked, built source code in ~/, one folder per version, and removes them only when its cleanup option is given at install time.
That makes ~/ worth a look on a Mac that uses ruby-install. It may also hold your own projects, so move only the folders and archives named after a Ruby version.
asdf and mise
asdf and mise manage many languages, and keep Ruby with the others: ~/ and ~/, one folder per version, gems included.
Both remove one version at a time with their own uninstall commands, and the catalog leaves these folders to them. mise can also prune: it remembers each configuration file it has loaded, and removes installed versions that none of them still selects. Its prune has a dry run that lists what would go first.
mise's documentation says it installs Ruby from ready-built packages where they exist, and builds it with ruby-build otherwise. asdf's Ruby plug-in builds it from source.
What does a Ruby cost to reinstall?
It depends on how it's installed. ruby-build, which rbenv uses, downloads Ruby's source code and compiles it, and may build OpenSSL too. That needs Apple's Command Line Tools, and takes much longer than a download.
A ready-built Ruby, from mise or Homebrew, is mostly a download. Either way, the gems come back only when you or Bundler install them again, so a project's first start after a reinstall includes a full gem install.
| Version manager | Where versions live | How it removes one | What it can leave behind |
|---|---|---|---|
| rbenv | ~/.rbenv/versions | Its uninstall command, or the folder to the Trash | Kept sources in ~/.rbenv/sources, if you asked to keep them |
| rvm | ~/.rvm/rubies | Its remove command | Gemsets, sources and archives, after an uninstall |
| chruby with ruby-install | ~/.rubies | The folder to the Trash | Gems in ~/.gem/ruby, sources in ~/src |
| asdf | ~/.asdf/installs/ruby | Its uninstall command | Nothing of note |
| mise | ~/.local/share/mise/installs/ruby | Its uninstall or prune commands | Version lists in its cache |
Homebrew's Ruby, and the Ruby you didn't know you had
Plenty of Macs have Ruby without anyone choosing it. It arrives with tools written in Ruby, and it collects gems like any other.
Why is there Ruby on a Mac that doesn't use Ruby?
Usually because of another tool. CocoaPods and fastlane, common on Macs that build iPhone apps, are Ruby programs. Homebrew's formulae for both need Homebrew's Ruby, so Homebrew installs it and lists it as installed as a dependency.
On the Mac measured below, Homebrew's Ruby had 132 gem folders. 38 were linked in from the gems that come with Ruby, and almost all the rest were fastlane and the gems it needs. The post on CocoaPods and SwiftPM caches covers CocoaPods' own downloads, which are separate.
Where Homebrew's Ruby keeps gems
Homebrew installs Ruby itself in its Cellar, but gems you install with it go to /, in a folder named after the Ruby version's series, such as 4.0.0. Homebrew's notes for the formula point there for the commands those gems add.
That folder isn't part of the formula, so Homebrew's cleanup doesn't look inside it. Gems stay until you uninstall them with RubyGems, and when Homebrew's Ruby moves to a new series, the new Ruby uses a new folder and no longer sees the old one.
Old Homebrew Rubies in the Cellar
Upgrading Homebrew's Ruby leaves the old version in / until Homebrew's cleanup removes it, which it normally does after an upgrade and every 30 days. On the Mac measured below, a version installed in April was still there two months after an upgrade in August.
The Cellar is Homebrew's to manage, never Finder's. The post on Homebrew cleanup explains why it keeps old versions and what to do about them.
The Ruby that comes with macOS
macOS still includes Ruby 2.6, at /, on the Mac measured here running macOS 27. Apple's release notes for macOS Catalina said these runtimes are included for compatibility with older software, and that future versions of macOS won't include them by default.
That Ruby is part of macOS, on the read-only system volume, and you can't remove it. Leave / alone too: its gem folder comes with macOS, and on the measured Mac it held under 2 MB.
Gems installed for macOS's Ruby
Installing gems for the system Ruby used to be the way to get CocoaPods. Gems installed with your password go into /; gems installed for your account only go into ~/.
If you've since moved CocoaPods and similar tools to Homebrew or a version manager, those older copies are no longer used. Uninstall them with RubyGems, using the system Ruby, so that their commands go too.
On the measured Mac, ~/ held only a cache folder of old .gem packages for CocoaPods and its dependencies, about 3 MB, with no gems installed beside them. A folder like that is safe to move to the Trash; RubyGems downloads a package again if it ever needs one.
Bundler: project gems and its caches
Bundler installs the gems a project's Gemfile asks for, at the exact versions in its Gemfile.lock. Where it puts them depends on the project's settings.
Where does Bundler install a project's gems?
By default, into the Ruby's own gem folder, shared with every other project on that Ruby. That's why gem folders collect several versions of popular gems over time, and why a version manager's Ruby folder grows as you work on more projects.
A project can set a path of its own instead. The usual one is vendor/bundle inside the project, which Bundler's deployment mode uses too. Then the project's gems live with the project, and nothing else uses them.
Is it safe to delete vendor/bundle?
Usually, once you've finished with the project. The catalog's entry for vendor/bundle (Bundler) marks it as needing your choice: Bundler can install everything again from the Gemfile and Gemfile.lock, but the project won't run until it does.
Reinstalling means downloading every gem and rebuilding the ones with native extensions, such as database drivers. For a project you'll open again next week, that's a cost; for one you've archived, it's the obvious folder to remove.
To find them, search for folders named bundle inside vendor folders in your projects, or open each project and look. Move the bundle folder, never the vendor folder, which can hold other things the project needs.
What's in ~/.bundle/cache?
Bundler's shared cache. It keeps information about the gems available on RubyGems.org so it doesn't fetch everything again for each install. With its global gem cache setting turned on, it also keeps downloaded gems and built extensions there for every project to share.
The catalog marks Bundler cache as safe. Bundler fetches anything it needs again, and your Bundler settings are in a separate file in ~/, so move only the cache folder.
What does Bundler's clean do?
It removes gems from a project's own gem folder that the project's Gemfile.lock no longer lists, which helps after many dependency changes. It works without extra options only when the project has a path of its own, such as vendor/bundle.
When a project uses the shared gem folder, Bundler refuses, and says that cleaning all the gems on your system is dangerous. Forcing it removes every gem in that folder that this one project doesn't use, including gems your other projects and tools need. Bundler can also clean automatically after each install, if a setting turns that on.
Is vendor/cache the same thing?
No. vendor/cache holds the .gem files Bundler's cache command copies into a project, so it can install without reaching RubyGems.org. Teams often keep that folder in the project's Git repository.
Treat it as part of the project. If the project's history includes it, deleting it changes the project, not just your Mac.
Other Ruby leftovers
A few smaller folders round out Ruby's footprint. None is usually large, but each has its own rule.
RubyGems' spec cache
RubyGems keeps the list of gems available on RubyGems.org, so it can resolve and search without downloading the whole list each time. According to RubyGems' code, it's in ~/ if that folder exists, and otherwise in ~/.
On the Mac measured below it was 28 MB, more than the gems installed for macOS's Ruby. It's a cache: RubyGems downloads the list again when it next needs it. Moving the specs folder to the Trash costs only that download.
ruby-build's cache and kept sources
ruby-build normally keeps nothing. It builds in a timestamped folder in your temporary folder and removes it, unless the build fails, when it leaves the folder for you to inspect.
Two settings change that. If a cache folder exists in ~/, ruby-build keeps each download there. And installing with its keep option leaves the source code in ~/. Both are safe to move to the Trash; a later install downloads the source again.
Logs and temporary files in Rails projects
Rails writes a log for each environment in a project's log folder, and development.log grows with every request while you work. Apps that load the defaults of Rails 7.1 or later limit the development and test logs to 100 MiB each. Apps on older defaults have no limit.
A log is safe to move to the Trash once you don't need it. Stop the app's server first, because a running server keeps writing to the file it opened; Rails starts a new log when it next starts.
The project's tmp folder is similar. Rails' guides call it the holding place for temporary files such as process IDs and cached actions, and its cache folder can be cleared the same way, with the server stopped.
Don't confuse storage with cache
A Rails project's storage folder is different. With Active Storage's local disk service, it holds files uploaded to your development app, and new apps that use SQLite keep their databases there by default.
That's data, not cache. Remove it only when you're done with the project, and only if you don't need what's in it.
A worked example: one Mac's Ruby
This Mac belongs to a developer who builds iPhone apps and doesn't write Ruby. It has no version manager, which makes it a useful baseline: everything here arrived with other tools.
- Gems for Homebrew's Ruby (132 folders)73.1 MB
- Older Homebrew Ruby still in the Cellar66.2 MB · Review first
- Current Homebrew Ruby64.4 MB · Review first
- macOS's own Ruby62 MB
- RubyGems' spec cache28.3 MB
- Old gem downloads for macOS's Ruby3.2 MB
Measured on one Mac in October 2026 as file sizes. The gem folder total includes 10.7 MB of .gem packages. macOS's Ruby is part of the system and counted under macOS, not System Data.
The gems, the two Homebrew Rubies and macOS's Ruby were each around 60 to 75 MB. On a Mac with a version manager, every installed version adds one Ruby of that size plus its gems.
What gem cleanup would find here
Eight gems had two versions, among them rake, rdoc, irb and csv. In every case the older one was the copy that came with Ruby, which Homebrew links in from Ruby's own folder, so it took almost no space of its own.
Cleaning up old gem versions would have freed close to nothing. That's typical of a gem folder used by one or two tools that are kept up to date.
What each step would free on this Mac
| Step | Space it frees | Can you undo it? |
|---|---|---|
| Let Homebrew's cleanup remove the old Ruby | About 66 MB | No |
| Move RubyGems' spec cache to the Trash | About 28 MB | Yes, until you empty the Trash |
| Uninstall fastlane, if no longer used | Most of the 73 MB gem folder | Reinstall to get it back |
| Remove old gem downloads for macOS's Ruby | About 3 MB | Yes, in Finder |
| Clean up old gem versions | Almost nothing | No |
What that means for your Mac
If you don't write Ruby, its footprint is small and stays small, as long as Homebrew's cleanup runs. The gems your tools need are the bulk of it, and they go when the tools do.
If you do, the numbers scale with versions and projects. Ten versions in ~/, each with a Rails app's gems, is a different order of size, and removing the unused versions is where the space is.
Mistakes to avoid
Ruby's folders look like ordinary folders in Finder, and some of them are safe to move there. Most problems come from treating the rest the same way.
Don't remove the whole version manager folder
Moving ~/, ~/ or ~/ to the Trash removes every Ruby you have, and leaves your shell's settings pointing at something that's gone. rbenv's README describes that as uninstalling rbenv itself, which it is. Remove versions one by one instead.
Don't remove a version a project still names
The error a project shows when its Ruby is missing is easy to fix, but the reinstall isn't instant. Check .ruby-version files first, including in projects you open only now and then, such as a personal site.
Don't force Bundler's clean on a shared gem folder
Bundler's warning is there for a reason. Forced in a project that uses the shared folder, its clean keeps only that project's gems and removes everyone else's, including tools such as CocoaPods.
Don't touch macOS's Ruby
/ and the system's Ruby framework are part of macOS. Apple has said future versions of macOS won't include them by default, which is Apple's decision to make, not a cleanup step.
Don't paste cleanup commands from a web page
RubyGems' and Bundler's cleanups are commands, and a command copied from a web page can do much more than it says. The steps here that free the most, removing an rbenv or chruby version and clearing caches, work in Finder, and the Trash lets you change your mind.
Keep Ruby's footprint small
Ruby's space comes from versions and projects, so it grows with your work and shrinks only when you remove what you've finished with.
A routine that works
- Use one version manager. Two managers mean two copies of the same Ruby, each with its own gems.
- When you move a project to a new Ruby, check whether anything else still uses the old one, and remove it if not.
- Every few months, let RubyGems clean up old gem versions in the versions you keep.
- Remove
vendor/bundlefrom projects you've archived. - Clear Bundler's cache and RubyGems' spec cache when you need room quickly.
Keep reinstalling cheap
A project's Gemfile.lock records every gem at its exact version, and its .ruby-version records the Ruby. With both in the project's repository, removing a version or a project's gems costs a reinstall, never the project.
The same approach works for other languages. The post on Python environments covers pyenv, conda and venvs, which grow the same way. So do old Rust toolchains.
How often should you look?
When you finish moving projects to a new Ruby, and otherwise every few months. Ruby releases a new version each December, and that's when old versions usually start to pile up.
How the app does it
Wombit explains Ruby's folders like everything else on the disk. Select one in the map or the list, and the inspector says what it is, how safe it is to remove and what removing it costs, from the catalog's entry. It reads only names, sizes and dates, and file names and paths never leave your Mac.
Cleanup lists them by level:
- Bundler's cache is Safe and starts checked.
- A project's
vendor/bundleis Usually safe and waits for you to check it. - rbenv's Ruby versions are Review first: each one is listed with what removing it costs, and goes only if you choose it.
- asdf's and mise's versions, and Homebrew's Cellar, are explained, with the tool's own way to remove them.
Folders go to the Trash, where Put Back returns them. For mise's cache, the app runs mise's own cleanup instead, after the review sheet; what it removes can't be put back.
What the app runs, after you review itPRO
- mise cache clear
- mise's cache of version lists and task results; installed tools stay
Folders no catalog entry explains, such as rvm's Rubies or RubyGems' spec cache, are never offered for removal. On a Mac with Apple Intelligence, the inspector can give a Best guess at what one is, labelled as a guess.
~/
.rbenv/ versions/ * Ruby versions installed with rbenv
A version of Ruby installed with rbenv, along with the gems installed for it.
Review first · Moves it to the Trash
~/
.bundle/ cache Gem information, and sometimes gems, that Bundler keeps to make installs faster.
Safe · Moves it to the Trash
~/
**/ vendor/ bundle A Ruby project's gems, installed inside the project by Bundler.
Usually safe · Moves it to the Trash
~/
.asdf/ installs Versions of languages and tools that asdf has installed through its plugins, one folder for each tool and version.
Review first · Explained only: never removed
~/
.local/ share/ mise/ installs Versions of Node.js, Python, Go and other tools that mise has installed, one folder for each tool and version.
Review first · Explained only: never removed
~/
Library/ Caches/ mise Information that mise, a tool version manager, keeps to work faster, such as the versions available for each tool.
Safe · Runs mise cache clear
Seeing all of this is free. Removing it is PRO, one $4.99 payment with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.
Frequently asked questions
How do I remove old gem versions on a Mac?
RubyGems' cleanup command removes older versions of gems that no other installed gem needs, keeping the newest version of each. It works on one Ruby at a time, so each version you keep is cleaned separately. Removing a whole Ruby version you no longer use frees more, because its gems go with it.
Does gem cleanup remove gems I don't use?
No. It only removes older duplicates of gems that have a newer version installed. A gem with one version installed stays, however long it's been since you used it; removing it takes RubyGems' uninstall command.
Can I delete a folder in ~/.rbenv/versions?
Yes, if no project still uses that version. rbenv's README says removing the version's folder is one way to uninstall it, and ruby-build's uninstall command is the other. That version's gems go with it, and a project that names it in .ruby-version won't run until you install it again.
Can I delete the Ruby that comes with macOS?
No. Ruby 2.6 at /usr/bin/ruby is part of macOS, on the read-only system volume. Apple has said future versions of macOS won't include scripting runtimes such as Ruby by default, but removing it isn't yours to do.
Where are Ruby gems installed on a Mac?
In the gem folder of the Ruby that installed them. For rbenv, asdf and mise, that's inside the version's own folder; for chruby, in ~/.gem/ruby; for Homebrew's Ruby, in /opt/homebrew/lib/ruby/gems. Gems for macOS's Ruby go to /Library/Ruby/Gems, or ~/.gem/ruby/2.6.0 when installed for your account only.
Can I delete vendor/bundle in an old Rails project?
Yes, once you've finished with the project. Bundler can install every gem again from the project's Gemfile and Gemfile.lock, but the project won't run until it does, and gems with native extensions are rebuilt. Move only the bundle folder, not vendor.
What's the difference between gem cleanup and bundle clean?
RubyGems' cleanup removes older versions of gems from a Ruby's gem folder. Bundler's clean removes gems a project's Gemfile.lock no longer lists from that project's own gem folder. Forced on a shared gem folder, Bundler's clean removes every gem that one project doesn't use, which is why it refuses by default.
Why do I have Ruby if I don't write Ruby?
Usually because a tool needs it. CocoaPods and fastlane are written in Ruby, and Homebrew installs its own Ruby for them. Uninstalling those tools is what removes their gems.
Sources
- Go directly to a specific folder on Mac · Apple
- macOS Catalina 10.15 Release Notes · Apple
- Command reference: gem cleanup and gem uninstall · RubyGems
- bundle clean · Bundler
- rbenv: uninstalling Ruby versions · rbenv
- Removing rubies · RVM