Published 17/06/2026

How to Use Podman with the GitHub MCP Server: Fixing the ENOENT Error on IBM Bob

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 start

To create the alias, add the following instruction to your shell configuration file (e.g., ~/.zshrc or ~/.bash_profile):

# Add to your ~/.zshrc alias docker=podman

Reload your terminal and verify it:

source ~/.zshrc
docker --version # Should return the Podman version

The 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 podman

sually, 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

Uncategorized