If you are exploring the new world of the Model Context Protocol (MCP) and trying to install the GitHub MCP server on IBM Bob, there is a good chance the documentation pointed you toward Docker. But what if you use Podman as your open-source, daemonless alternative?
In theory, Podman’s command compatibility should make the transition seamless. In practice, AI tools or managers like Bob/VS Code can run into unexpected environment issues.
In this post, we will look at how to properly configure Podman for the GitHub MCP Server and, more importantly, how to resolve the persistent command-not-found (ENOENT) error, even after setting up terminal aliases.
The Initial Plan: Creating a Docker Alias
Since Podman accepts the exact same syntax as Docker, the natural first attempt is to create a global alias so that the MCP Server triggers podman while thinking it is calling docker.
If you don’t have Podman set up via Homebrew (on macOS) yet, the initial setup is:
Installing and initializing Podman
brew install podman
podman machine init
podman machine startTo create the alias, add the following instruction to your shell configuration file (e.g., ~/.zshrc or ~/.bash_profile):
# Add to your ~/.zshrc alias docker=podmanReload your terminal and verify it:
source ~/.zshrc
docker --version # Should return the Podman versionThe Problem: “But docker –version works in VS Code and the error persists!”
You open VS Code, test the command in the integrated terminal, and it works flawlessly. However, the MCP Server (orchestrated by tools like Bob) refuses to boot up, breaking with an internal error or a classic ENOENT (Error No Entry / File not found).
Why does this happen?
Child processes spawned by extensions or tool managers within VS Code do not always inherit the aliases from your interactive shell (.zshrc). To the backend process trying to launch the MCP Server, the docker command simply does not exist within the system’s PATH.
Solution: Mapping the Real Path in mcp.json
Instead of relying on a volatile terminal alias, the most robust solution is to explicitly point the MCP Server to the Podman executable through its configuration file.
Step 1: Find Podman’s absolute path
Run the following command in your terminal to locate the exact binary path:
which podmansually, on macOS via Homebrew, this will return /opt/homebrew/bin/podman.
Step 2: Update the mcp.json file
Open your MCP environment configuration file (typically located at ~/.bob/mcp.json or your specific AI tool’s config directory) and locate the GitHub server block.
Replace the “command”: “docker” value with the absolute path to Podman you just discovered, ensuring the initialization arguments remain intact:
{
"mcpServers": {
"github": {
"command": "/opt/homebrew/bin/podman",
"args": [
"run",
"-i",
"--rm",
"-e",
"GITHUB_PERSONAL_ACCESS_TOKEN",
"-e",
"GITHUB_TOOLSETS",
"-e",
"GITHUB_READ_ONLY",
"-e",
"GITHUB_HOST",
"ghcr.io/github/github-mcp-server"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "your_token_here",
"GITHUB_TOOLSETS": "",
"GITHUB_READ_ONLY": "",
"GITHUB_HOST": ""
}
}
}
}Restart the terminal.
Save the file, completely close VS Code or the terminal inside IBM Bob
Now, the background process no longer has to guess what “docker” means. It will directly invoke the Podman binary from the specified path, isolating it from any shell environment inconsistencies