Prerequisites
Area
MCP
Problem or Motivation
Browser MCP connects successfully and registers its tools, but Chromium could not launch reliably in the Docker deployment.
The failures included missing Chromium runtime libraries, an unwritable Playwright cache, browser-profile locking, sandbox failure, and failure to select the installed Chromium executable.
Because MCP connects normally, the problem does not appear until a browser tool is actually used. This makes Browser MCP look available while navigation remains unusable.
Proposed Solution
Improve the Docker Browser MCP setup so it works without manual repair.
The working local implementation included:
- Installing the Chromium runtime libraries required by Playwright.
- Creating the Playwright cache directory and repairing its ownership for the Odysseus user.
- Starting Browser MCP with headless, no-sandbox, isolated, and vision options.
- Selecting the installed Playwright Chromium executable explicitly.
- Providing writable persistent npm, XDG, and Playwright cache paths.
For an upstream implementation, the Chromium executable and writable paths should preferably be detected or configurable rather than tied to one Chromium revision or one hardcoded /app path.
Alternatives Considered
I considered leaving these changes in docker-compose.override.yml and maintaining them only as a local installation repair.
That works, but it means other Docker users can encounter the same failures and must diagnose the Chromium dependencies, permissions, sandbox, profile, and executable-path issues independently.
I also used an exact local Chromium executable path. That proves the repair works, but automatic detection or configuration would be more suitable upstream.
Prior Art / Related Issues
I searched the open issues and discussions and did not find an existing report covering this combination of Browser MCP Docker failures.
The repair is currently saved in my local repository as commit:
2d0bf51 fix(browser-mcp): make Chromium usable in Docker
It has not been pushed or submitted as a pull request.
Are you willing to implement this?
Yes — I can open a PR
Prerequisites
Area
MCP
Problem or Motivation
Browser MCP connects successfully and registers its tools, but Chromium could not launch reliably in the Docker deployment.
The failures included missing Chromium runtime libraries, an unwritable Playwright cache, browser-profile locking, sandbox failure, and failure to select the installed Chromium executable.
Because MCP connects normally, the problem does not appear until a browser tool is actually used. This makes Browser MCP look available while navigation remains unusable.
Proposed Solution
Improve the Docker Browser MCP setup so it works without manual repair.
The working local implementation included:
For an upstream implementation, the Chromium executable and writable paths should preferably be detected or configurable rather than tied to one Chromium revision or one hardcoded /app path.
Alternatives Considered
I considered leaving these changes in docker-compose.override.yml and maintaining them only as a local installation repair.
That works, but it means other Docker users can encounter the same failures and must diagnose the Chromium dependencies, permissions, sandbox, profile, and executable-path issues independently.
I also used an exact local Chromium executable path. That proves the repair works, but automatic detection or configuration would be more suitable upstream.
Prior Art / Related Issues
I searched the open issues and discussions and did not find an existing report covering this combination of Browser MCP Docker failures.
The repair is currently saved in my local repository as commit:
2d0bf51 fix(browser-mcp): make Chromium usable in Docker
It has not been pushed or submitted as a pull request.
Are you willing to implement this?
Yes — I can open a PR