[Bug]: Internal MCP self-connection fails with "405 Method Not Allowed" on rootless Podman (blocks all conversations)

[patmansk]

Operating System

Linux

Installation Method

Other

Agent Canvas Version

ghcr.io/openhands/openhands:latest (SDK v1.36.0)

Bug Description

Is there an existing issue for the same bug?
I have searched existing issues and this is not a duplicate.
Related: OpenHands/OpenHands#13861 (closed as stale, not fixed) and OpenHands/OpenHands#16201 (same underlying code path, different symptom — SSL record layer failure instead of 405)

Installation Method

Podman (rootless, user-scoped, via Quadlet) — main app container + dynamically created oh-agent-server-* sandbox containers

Bug Description

Every new conversation fails as soon as a message is sent. The internal MCP client inside the dynamically created oh-agent-server-* sandbox container tries to connect to OpenHands' own built-in MCP endpoint and fails with 405 Method Not Allowed. This happens even with mcp_config: {} (no user-configured MCP servers) and blocks the agent from responding at all — not a cosmetic warning.

What I've tried
Confirmed host.docker.internal resolves correctly from the sandbox container (this is not a DNS issue — unlike the LAN-IP case in OpenHands/OpenHands#16201, my WEB_HOST defaults to localhost/host.docker.internal).
Setting Environment=WEB_HOST=host.docker.internal:3000 (no scheme) → changes the failure mode to httpx.ConnectError: [SSL] record layer failure (_ssl.c:1032) — the internal MCP client apparently now attempts HTTPS against a plain-HTTP port. Same underlying issue as OpenHands/OpenHands#16201.
Setting Environment=WEB_HOST=http://host.docker.internal:3000 (explicit scheme) → still fails, "MCP Connection Failure" (same SSL error).
Removing WEB_HOST entirely → back to the original 405.

None of these env var combinations fix it. This strongly suggests the bug is in how the agent-server derives/uses the internal MCP server URL (meta.json / mcp_oauth_store.py) rather than something fixable purely via environment configuration — consistent with the root cause described in OpenHands/OpenHands#13861.

Impact
OpenHands is completely unusable for chat/conversations in this deployment (rootless Podman, Quadlet, sandbox containers created dynamically via the Docker-compatible socket API). This is not an edge case — it reproduces on every single new conversation and every message.
Environment details
Host: Linux (Nobara 44, Fedora-based), Podman 5.8.4 rootless (user-scoped systemd Quadlet units)
Main container: ghcr.io/openhands/openhands:latest
Sandbox container: ghcr.io/openhands/agent-server:1.36.0-python
mcp_config: empty / default (no user-configured MCP servers)
LLM: local Ollama backend (qwen3-coder:30b) — confirmed unrelated to the bug, error occurs before any LLM call

Steps to Reproduce

Run OpenHands via rootless Podman (Quadlet), main container joined to a pod, with the Docker socket mounted for dynamic sandbox creation:
Volume=/run/user/1000/podman/podman.sock:/var/run/docker.sock:rw
Start a new conversation.
Send any message, e.g. "Hallo".
Observe the UI error:
Client error '405 Method Not Allowed' for url 'http://host.docker.internal:3000/mcp/mcp'

Actual Behavior

Every message send attempt in every new conversation fails immediately with MCPError: MCP Connection Failure or the underlying 405/SSL error, regardless of the configured LLM/model. The conversation is unusable.

Expected Behavior

Sending a message should not depend on a successful connection to the internally-registered "default" MCP server if it's not needed / not configured by the user.
At minimum, the built-in self-MCP-connection should not throw an unhandled error that aborts _ensure_agent_ready and prevents any response from being generated.

Relevant Logs

Error / Traceback
Traceback (most recent call last):
  File "openhands/agent_server/sockets.py", line 351, in events_socket
  File "openhands/agent_server/event_service.py", line 499, in send_message
  ...
  File "openhands/sdk/conversation/impl/local_conversation.py", line 1365, in _ensure_agent_ready
  File "openhands/sdk/conversation/impl/local_conversation.py", line 1201, in _runtime_mcp_tools_for_agent
  File "openhands/sdk/conversation/impl/local_conversation.py", line 1193, in _runtime_mcp_tools
  File "openhands/agent_server/mcp_oauth_store.py", line 334, in create_tools
  File "openhands/sdk/mcp/client.py", line 97, in sync_close
  ...
  File "mcp/client/streamable_http.py", line 358, in _handle_post_request
  File "httpx/_models.py", line 829, in raise_for_status
httpx.HTTPStatusError: Client error '405 Method Not Allowed' for url 'http://host.docker.internal:3000/mcp/mcp'

Additional related failures in the same logs (webhook posts, also 405, also to the main container):

Conversation webhook post attempt 4 failed: Client error '405 Method Not Allowed' for url 'http://host.docker.internal:3000/api/v1/webhooks/conversations'
Failed to post events to webhook http://host.docker.internal:3000/api/v1/webhooks/events/<id> after 4 attempts

Screenshots

No response

Additional Context

This looks like the same root cause as OpenHands/OpenHands#13861 (internal MCP URL / meta.json not reflecting the correct web_url) and OpenHands/OpenHands#16201 (SSL failure when WEB_HOST is set to a non-default value). OpenHands/OpenHands#13861 was auto-closed as stale without a fix being merged. OpenHands/OpenHands#16201 was closed by the reporter as "completed" but without any comment explaining the resolution, so it's unclear whether an actual code fix was applied or merged.

Given three independent reports hitting the same code path (mcp_oauth_store.py → _runtime_mcp_tools) with different symptoms depending on network/WEB_HOST configuration, I'd like to request that this be reopened/tracked as a confirmed bug rather than closed without a resolution being documented.

[onatozmenn]

Had a dig through this since the same code path keeps coming back. Two separate things are going on here, and I think only one of them is a bug in the usual sense.

Why none of the WEB_HOST variants worked. get_default_web_url in the app server does this:

web_host = os.getenv('WEB_HOST')
if not web_host:
    return None
return f'https://{web_host}'

(openhands/app_server/config.py in OpenHands/sandbox-server)

The scheme is hardcoded. WEB_HOST=host.docker.internal:3000 becomes https://host.docker.internal:3000, which is a TLS handshake against a plain HTTP port, so you get [SSL] record layer failure. And WEB_HOST=http://host.docker.internal:3000 becomes https://http://host.docker.internal:3000. That explains why your three attempts failed in different ways but none of them helped: there is currently no way to point the app at a plain HTTP callback host.

Where the 405 comes from. With no WEB_HOST the conversation service falls back to http://host.docker.internal:{sandbox_service.host_port} and builds the built-in server as f'{web_url}/mcp/mcp'. host_port defaults to 3000 and is documented as "the port on which the main OpenHands app server is running". The webhook callback comes off the same field, f'http://host.docker.internal:{self.host_port}/api/v1/webhooks', which is why your log shows 405 on both the MCP connect and the webhook posts. So whatever answers on 3000 in your pod is not the app server, and it returns 405 to a POST rather than 404, which is what a frontend route handler does rather than a missing route.

On your side OH_SANDBOX_HOST_PORT is the knob that matters if the app server sits on a different port in the Quadlet layout. But the reason you could not work around any of this with WEB_HOST is a real bug.

I'm happy to send a small PR for the scheme handling: keep https:// as the default so nothing changes for cloud, but pass a WEB_HOST through untouched when it already carries a scheme. That at least gives self-hosted deployments a working escape hatch.

Separately, a dead MCP server should not be taking the whole conversation down in the first place. #4454 covers that and #4462 is open for it, so once that lands the conversation would at least start.

[github-actions]

⚠️ Not yet ready-for-dev

This issue does not yet meet the readiness criteria, so the
ready-for-dev label has not been applied (or has been removed).
The criteria are type-specific:

Bug reports (bug label):

• The ### Actual Behavior section must describe reproducible SDK steps
  and include a command such as python, pytest, uv, or pip.
• An ### Acceptance Criteria section with at least one checklist item (- [ ] …).

Enhancements (enhancement label):

• A ### Desired Behavior section.
• An ### Acceptance Criteria section with at least one checklist item.

What is missing:

• The Actual Behavior section must include a reproducible SDK command such as python, pytest, uv, or pip.
• Add an ### Acceptance Criteria section with testable checklist items.

Edit the issue to address the gaps and the ready-for-dev label will be
applied automatically.

This is an automated check — no AI was used to generate this comment.

[neubig]

Hey @onatozmenn we'd welcome a PR for this

[all-hands-bot]

#4493 overlaps with #4454 on MCP-failure-kills-conversation but adds a distinct WEB_HOST scheme-handling bug (hardcoded https://) not covered elsewhere. Already cross-linked by a commenter; a maintainer has engaged.

Found 2 possible duplicate issues:

1. #4454 — MCP server connection failure at startup aborts the whole conversation (should degrade, not 500)
2. #4245 — [Bug]: Agent-Server Webhook Connection Failures Cause Container Crashes and Sandbox Connection Errors

These may not be exact duplicates, but the scope appears to overlap enough that keeping discussion in one place may be more useful.

This comment was created by an AI assistant (OpenHands) on behalf of the repository maintainer.

[xiehuanyi]

Scheme handling for WEB_HOST lives in OpenHands/sandbox-server (get_default_web_url), not in this SDK repo. I opened a PR there:

OpenHands/sandbox-server#7

Bare hosts still get https://. WEB_HOST=http://host.docker.internal:3000 is now passed through instead of becoming https://http://....

The 405 with no WEB_HOST is the docker fallback http://host.docker.internal:{host_port} hitting whatever is on that port. OH_SANDBOX_HOST_PORT is the deployment knob for that. Conversation abort on MCP connect is still #4462.