Here’s a breakdown of the problem and some potential solutions:
Problem Summary:
- Laravel (and Boost) inside Docker; Claude MCP/Code on host.
- Boost and Claude use stdio for communication (cannot connect across containers or between host/container).
- You want to keep Claude on the host but allow Boost (in Docker) to talk to it.
- Docker network aliases for databases, etc., don’t work for host programs.
- You don’t want to duplicate Claude container for every app.
Solution 1: Use Host Networking for Boost (Not Recommended for Mac/Windows)
Host networking (--network=host) allows container to see the host’s network—but generally only available on Linux, and even then it exposes security risks and can cause port conflicts.
Solution 2: Socket or TCP Proxy Bridge for Stdio
Since stdio can’t cross the host/container boundary, use a small proxy to bridge the gap:
A. Run Boost on Host (with a TCP connection instead of stdio):
See if Boost supports any form of TCP communication or WebSocket instead of only stdio. If so, you could run Boost on your host and point it at your Dockerized services by setting .env variables to the host address.
But, for many Boost setups, only stdio is expected.
B. Pipe stdio Across the Boundary with a Proxy
-
Create a Local Proxy Script
Use socat or a small Node/Python script to bridge stdio (Claude <-> Boost):- On your host, run Claude as usual (it listens on stdio: pipes).
- Also run a TCP proxy that listens on a port and forwards input/output to Claude’s stdio.
- In Docker, run Boost and configure it to use a TCP connection to the host (if possible).
- If Boost only does stdio, you may need another containe/local process that proxies stdio to TCP (a wrapper script).
-
Example socat bridge (host):
socat -d -d TCP-LISTEN:9001,reuseaddr,fork EXEC:"path/to/claude-mcp"Now, in Docker, connect Boost to host.docker.internal:9001 (this keyword works on Mac/Windows Docker).
If Boost does not support TCP at all, you will need to wrap it in a small script/program that connects stdio to TCP.
C. Use Unix Domain Sockets
If your host is Linux, you can also sometimes mount a Unix socket into both your container and host, but this is more complex and less portable.
Solution 3: Centralized Claude Service, Projects Connect by TCP
Run one Claude MCP/Code service on your host, expose a local TCP port, and have all your projects connect to that host:port (not by stdio). Use the same socat trick above.
Docker-to-host connectivity:
- In Docker, instead of
localhostor127.0.0.1, usehost.docker.internal(on Mac+Windows), or your host’s IP (on Linux). - Set your Laravel/Boost configs to use this TCP port.
Solution 4: Custom Wrapper
Write a small wrapper in Node.js, Python, or even PHP that:
- Listens to a TCP port (from inside Docker).
- Pipes TCP input/output to the local Claude process’s stdio.
Example (Node.js pseudo-code):
const net = require('net');
const { spawn } = require('child_process');
const claude = spawn('path/to/claude-mcp');
const server = net.createServer(socket => {
socket.pipe(claude.stdin);
claude.stdout.pipe(socket);
});
server.listen(9001);
Now, Boost in Docker connects to TCP port 9001 on the host.
Summary
There’s no perfect solution unless Boost/Claude add true TCP support. The most robust current option:
- Run Claude on host, and bridge stdio to TCP with socat or a small script.
- In Docker, connect to host.docker.internal:9001.
- If Boost requires stdio inside Docker, wrap it similarly with a proxy on the Docker side.
TL;DR:
You need a TCP bridge/proxy that speaks stdio with Claude, and a way for Boost inside Docker to use TCP to talk to that proxy.
Further Reading/References:
- [Docker: host.docker.internal won’t work on Linux natively; see docs].
- socat example (stdlib proxy).
Ask your team: If you find stdio too limiting, it may be worth opening a feature request with Boost/Claude for proper TCP or Unix socket support.
Sample Docker Compose snippet for Boost:
services:
laravel:
build: .
environment:
- REDIS_HOST=redis
- CLAUDE_HOST=host.docker.internal
- CLAUDE_PORT=9001
# ...etc
Let me know if you need a full proxy implementation!