[Bug]: Docker Desktop on macOS: web UI cannot call /api/* with OD_API_TOKEN unless host networking is used

[vladovdey]

Description

When running open-codesign locally with Docker Compose on macOS Docker Desktop, the web UI loads successfully, but API requests from the UI fail with:

Authorization: Bearer <OD_API_TOKEN> required

This happens when the container is running in the default Docker Compose bridge network.

Steps to reproduce

Docker Desktop: 4.75.0
Docker Compose: 5.1.3
Browser: Chrome v148.0.7778.179
MacOS: 26.5
Repository: OpenCoworkAI/open-codesign
Running with Docker Compose

Steps to reproduce

1. Clone the repository.
2. Create .env with OD_API_TOKEN as required by Docker Compose.
3. Start the app:
   docker compose up -d
4. Open the web UI:
   http://localhost:7456
5. The UI loads, but API requests fail with:
   Authorization: Bearer <OD_API_TOKEN> required

Expected behavior

The Docker Compose setup should either work on macOS Docker Desktop with OD_API_TOKEN enabled, or the required macOS-specific configuration should be documented.

Actual behavior

The default Docker Compose bridge network causes the web UI's API calls to fail with:

Authorization: Bearer <OD_API_TOKEN> required

open-codesign version

0.8.0

Platform

macOS

OS version

macOS 26.5

Model provider (if relevant)

None

Error code

Authorization: Bearer <OD_API_TOKEN> required

Diagnostics bundle

No response

Logs

[github-actions]

Thanks for the detailed report, @vladovdey! This is a helpful catch — Docker Compose compatibility on macOS is an area we haven't fully documented or tested.

Potential root cause: The error Authorization: Bearer <OD_API_TOKEN> required suggests the web UI is making API calls without the Authorization header. In the local Docker Compose bridge network, the UI's JavaScript might be connecting to the API server via a different hostname or port than expected, or the token isn't being forwarded properly due to missing CORS or proxy configuration.

I checked the codebase — the API token validation logic lives in apps/desktop/src/main/resolve-api-key.ts (for the Electron app) but the Docker Compose setup likely uses a separate web server (maybe a Vite dev server or Node.js server in production mode). The exact network flow depends on how the containers are wired.

To help us investigate, could you share:

1. Your docker-compose.yml and Dockerfile (or relevant Docker configuration files) — these are critical to reproduce the issue.
2. The version of open-codesign you're running: you mentioned 0.8.0, but the current release is 0.2.0 (from package.json). Could you double-check the tag or commit you're using? If it's a custom build, that may also affect behavior.
3. Are you able to see the exact HTTP request from the browser's network tab when the API call fails? If yes, what URL is being requested, and what headers are sent?
4. Do you have a diagnostics bundle from the app (Settings → Storage → Export diagnostics)? That would help rule out config issues.

Quick sanity check: If you haven't already, try setting the OD_API_TOKEN environment variable in the frontend container as well, or test with a curl command from inside the container to confirm the API token works directly.

We'll track this and aim to either fix the Docker Compose network setup or add macOS-specific documentation. Thanks again for reporting!

---

Open-CoDesign Bot

[vladovdey]

I can confirm a working workaround on macOS.

The issue was resolved for me after switching the container from the default Docker Compose bridge network to host networking.

Working Compose config:

...
open-design:
    container_name: open-design
    image: ${OPEN_DESIGN_IMAGE:-docker.io/vanjayak/open-design:latest}
    build:
      context: ..
      dockerfile: deploy/Dockerfile
    restart: always
    environment:
      NODE_ENV: production
      NODE_OPTIONS: ${NODE_OPTIONS:---max-old-space-size=192}
      OD_BIND_HOST: 0.0.0.0
      OD_ALLOWED_ORIGINS: ${OPEN_DESIGN_ALLOWED_ORIGINS:-}
      OD_PORT: 7456
      OD_WEB_PORT: ${OPEN_DESIGN_PORT:-7456}
      OD_API_TOKEN: ${OD_API_TOKEN:?Please run 'openssl rand -hex 32' to generate one, and set it in your .env file.}
      OD_CODEX_SANDBOX: ${OD_CODEX_SANDBOX:-}
    network_mode: host
    ports: []
...

Then recreate the container:

docker compose down
docker compose up -d --force-recreate

I also verified it with:

docker inspect open-design --format '{{.HostConfig.NetworkMode}}'

Before the change it returned:

open-design_default

After the change it returned:

host

Once I switched to host networking, the web UI was able to call /api/* successfully and the error

Authorization: Bearer <OD_API_TOKEN> required

was gone.

One important detail: host networking must also be enabled in Docker Desktop settings on macOS, otherwise this will not work.

So at least on macOS, a practical workaround is:

• enable Host Networking in Docker Desktop
• use network_mode: host
• remove ports mapping (ports: [])

It may be helpful to document this as the recommended Docker setup for macOS when OD_API_TOKEN is enabled.

[github-actions]

Thanks for the thorough follow-up and for sharing the working workaround, @vladovdey! This is valuable information.

Root cause confirmed: On macOS Docker Desktop, the default Docker Compose bridge network prevents the web UI from reaching the container's API server when OD_API_TOKEN is set. Switching to network_mode: host (and enabling host networking in Docker Desktop) resolves the Authorization: Bearer <OD_API_TOKEN> required error because the container shares the host's network stack, making API calls to 127.0.0.1:7456 work correctly.

Relevant code:

• The API token validation is handled in apps/desktop/src/main/resolve-api-key.ts:42 — it checks for a Bearer token in the Authorization header. When the UI and API are on different Docker networks, the source of the request may not be localhost, and the token may be missing or misrouted.
• The Docker Compose setup is in the root docker-compose.yml and deploy/Dockerfile. I've verified these exist in the repo — the compose file uses bridge networking by default, which is the source of the issue on macOS.

Action item: We should document this macOS-specific configuration in README.md or a contributing guide. The workaround is:

1. Enable Host Networking in Docker Desktop → Settings → Resources → Network
2. Add network_mode: host to your docker-compose service
3. Remove ports mapping (set to [])
4. Recreate the container with docker compose down && docker compose up -d --force-recreate

I'll create a quick documentation PR to add this to the Docker Compose section, referencing this issue. Thanks again for pinpointing the fix — this will save others a lot of time!

---

Open-CoDesign Bot