🚀 Executive Summary
TL;DR: If Docker containers are running in your terminal but not visible in Docker Desktop, it’s typically due to a context mismatch or WSL2 integration issues. Resolve this by checking and switching Docker contexts, enabling WSL2 integration for your distro, or unsetting conflicting DOCKER_HOST/DOCKER_CONTEXT environment variables.
🎯 Key Takeaways
- The primary reason for containers not appearing in Docker Desktop GUI despite running in the terminal is a ‘Context Mismatch’, where the CLI and GUI are pointed at different Docker Engines.
- For Windows users leveraging WSL2, Docker Desktop requires explicit ‘WSL Integration’ to be enabled for specific Linux distributions to properly display containers run from within those distros.
- Conflicting environment variables like `DOCKER_HOST` or `DOCKER_CONTEXT` can override Docker Desktop’s default settings, forcing the CLI to connect to an unintended or non-existent Docker Engine.
If your containers are running in the terminal but invisible in the Docker Desktop GUI, you’re likely facing a context mismatch or a WSL2 integration disconnect. This guide helps you sync your environments so you can manage your stack without the headache.
Ghost in the Machine: Why Your Containers Aren’t Showing Up in Docker Desktop
I remember a frantic Tuesday night at TechResolve when a junior engineer paged me because our staging-app-04 containers had “vanished.” He could see them in his terminal, he could curl the API, but his Docker Desktop dashboard was a ghost town. He was convinced he’d broken the local daemon. It’s a classic “in the trenches” moment that makes you feel like you’re losing your mind, but the reality is usually much more mundane: your CLI and your GUI are simply looking at two different things.
The “Why”: It’s All About the Context
The root cause is almost always a Context Mismatch. Docker isn’t just one monolithic thing; it’s a client-server architecture. Your CLI (the client) can be pointed at any number of Docker Engines (the server). If your terminal is looking at a specific WSL2 distro, a remote server like dev-sandbox-01, or a legacy Minikube instance, but your Docker Desktop GUI is looking at the default desktop-linux engine, you won’t see a thing in the dashboard.
The Fixes
1. The Quick Fix: Check Your Context
Before you restart anything, check where your terminal is actually pointing. It’s common for tools to swap your context without you realizing it.
# List your current contexts
docker context ls
# If the '*' is not on 'desktop-linux' (or 'default'), switch back
docker context use defaultPro Tip: If you see “default” and “desktop-linux”, try switching between them. Sometimes a legacy installation leaves a “default” context that points to a non-existent socket.
2. The Permanent Fix: Enable WSL2 Integration
If you are on Windows and using WSL2 (like Ubuntu or Debian), Docker Desktop needs explicit permission to “inject” its binaries into that specific distribution. If this isn’t toggled on, your docker ps in Ubuntu is effectively shouting into a void.
- Open Docker Desktop Settings.
- Navigate to Resources > WSL Integration.
- Ensure “Enable integration with my default WSL distro” is checked.
- Find your specific distro (e.g., “Ubuntu-22.04”) in the list and toggle it to ON.
3. The “Nuclear” Option: Clearing Environment Variables
Sometimes, a previous project or a stray script might have hardcoded a DOCKER_HOST environment variable in your .bashrc or .zshrc. This overrides everything else and forces the CLI to look at a specific network socket.
| Variable | What it does | The Fix |
| DOCKER_HOST | Overrides the engine location. | Run unset DOCKER_HOST |
| DOCKER_CONTEXT | Forces a specific context. | Run unset DOCKER_CONTEXT |
To make this stick, check your shell profile for any lines that look like export DOCKER_HOST=tcp://localhost:2375 and comment them out. I’ve seen this happen a dozen times after someone tries to “fix” a connection issue and ends up hardcoding a path that breaks the GUI sync.
Warning: Restart your terminal after unsetting these variables to ensure the changes propagate correctly.
At the end of the day, Docker Desktop is just a fancy lens into the engine. If the lens is pointed at the wrong engine, you won’t see the picture. Keep your contexts clean, and you’ll spend less time troubleshooting the tool and more time shipping code.
🤖 Frequently Asked Questions
âť“ Why are my Docker containers not showing in Docker Desktop even though they are running in the terminal?
This usually stems from a ‘Context Mismatch’ where your terminal’s Docker CLI is pointed at a different Docker Engine than the one Docker Desktop GUI is monitoring, or a WSL2 integration disconnect if you’re on Windows.
âť“ What are the primary methods to resolve Docker containers not appearing in Docker Desktop?
The main methods involve checking and switching your Docker context using `docker context use default`, ensuring WSL2 integration is enabled for your specific distribution in Docker Desktop settings, or clearing potentially conflicting `DOCKER_HOST` or `DOCKER_CONTEXT` environment variables.
âť“ What is a common pitfall when troubleshooting Docker Desktop container visibility?
A common pitfall is having `DOCKER_HOST` or `DOCKER_CONTEXT` environment variables hardcoded in your shell profile (e.g., `.bashrc`, `.zshrc`), which can override Docker Desktop’s default settings and point your CLI to an incorrect or non-existent Docker Engine.
Leave a Reply