Android/Termux remote startup: config fetch returns 403 in v0.2.48

Upstream report

Summary

@wonderwhy-er/desktop-commander version 0.2.48 cannot start its remote device on the qualified Android/Termux subject. The local MCP connection succeeds, but the subsequent remote configuration fetch terminates startup with:

Device startup failed: Failed to fetch Supabase config: Forbidden

The failure persists without VPN even though a contemporaneous standalone request to the same public configuration path returns HTTP 200. This leaves a package/process-context-specific difference that has not yet been explained.

Exact runtime subject

PLATFORM=android
ARCH=arm64
NODE=v24.18.0
NPM=11.19.1
NPX=11.19.1
DESKTOP_COMMANDER=0.2.48
PACKAGE=@wonderwhy-er/desktop-commander

Installed execution root was the npm/npx cache for this exact package version. Evidence from other hosts, versions, platforms, or cache roots was not treated as binding.

Minimal reproduction

1. On Android/Termux, ensure VPN is off.

2. Start exactly one process:

   bash复制

   npx @wonderwhy-er/desktop-commander@latest remote

3. Observe that local Desktop Commander MCP connects.

4. Observe remote startup fail during configuration fetch with Forbidden.

No retry, package edit, configuration reset, credential deletion, upgrade, downgrade, or proxy mutation was performed.

Expected result

The remote configuration request should receive HTTP 200, allowing authentication and channel initialization to proceed.

Actual result

LOCAL_MCP_CONNECTION=PASS
REMOTE_CONFIG_FETCH=FAIL_HTTP_403
AUTH=NOT_REACHED
CHANNEL_SUBSCRIPTION=NOT_REACHED
STABILITY_WINDOW=NOT_RUN
REMOTE_READ_ONLY_COMMAND=NOT_RUN

Sanitized differential evidence

VPN enabled — same configuration path

TIMESTAMP_UTC=2026-09-04T10:59:55Z
CURL_HTTP=403
NATIVE_FETCH_HTTP=403
NODE_HTTPS_HTTP=403

This confirms an independent VPN-egress effect: multiple clients receive the same HTTP 403 through that path.

VPN disabled — standalone control

CURL_HTTP=200
CURL_ERROR=0
ELAPSED_S=1.341253

VPN disabled — Desktop Commander

LOCAL_MCP_CONNECTION=PASS
REMOTE_CONFIG_FETCH=FAIL_HTTP_403_FORBIDDEN
DEVICE_STARTUP=FAIL
GRACEFUL_SHUTDOWN=PASS

The VPN-disabled comparison is the primary issue: standalone Curl receives 200, while Desktop Commander receives 403 before authentication or Realtime channel creation.

Previously qualified transport facts

PUBLIC_CONFIG_ROOT_HTTP=PASS
PUBLIC_CONFIG_INFO_HTTP=PASS_AT_EARLIER_OBSERVATION
NODE_NATIVE_FETCH_TO_CONFIG_INFO=PASS_200_AT_EARLIER_OBSERVATION
GENERAL_NETWORK_FAILURE=REJECTED
ANDROID_TLS_FAILURE=REJECTED
REMOTE_SERVICE_TOTAL_OUTAGE=REJECTED

Separate Realtime observations showed successful WebSocket upgrade and initial heartbeat replies followed by transport failure near 60–65 seconds. Those observations are retained as secondary evidence and are not asserted to cause the configuration-fetch 403, which occurs earlier in startup.

Source observations

Read-only inspection identified the throw site in:

dist/remote-device/device.js

Observed logic performs a fetch to the package's base-server configuration path and throws Failed to fetch Supabase config: <statusText> when response.ok is false. No installed source files were edited.

Installed related client versions observed:

@supabase/realtime-js=2.115.0
@supabase/phoenix=0.4.5

Requested maintainer guidance

Please advise whether the remote configuration request in version 0.2.48 adds process-specific headers, dispatcher behavior, request metadata, or other context that could cause an edge/service policy to return 403 when a standalone request from the same Android/Termux environment returns 200.

Useful maintainer-side diagnostics would include, without exposing secrets:

• final request URL shape with host and credentials redacted;
• request method and non-sensitive header names;
• effective fetch/dispatcher implementation;
• response status, edge request identifier, and policy classification;
• whether Android/Termux and Node 24 are supported for remote mode.

Safety posture

PACKAGE_PATCHED=NO
PACKAGE_UPGRADED=NO
PACKAGE_DOWNGRADED=NO
CONFIG_DELETED=NO
CREDENTIALS_DELETED=NO
SESSION_RESET=NO
NETWORK_MUTATED_BY_DIAGNOSTICS=NO
SECRETS_RECORDED=NO

Evidence decision

ROOT_CAUSE=RC-09_UNKNOWN
CONFIRMED_OPERATIONAL_BLOCK=REMOTE_CONFIG_FETCH_HTTP_403
VPN_EGRESS_EFFECT=CONFIRMED
VPN_OFF_PACKAGE_CONTEXT_DIFFERENCE=CONFIRMED
PACKAGE_INTERNAL_MECHANISM=NOT_PROVEN
DIRECT_REMOTE_ANDROID_SHELL=NOT_QUALIFIED
FINAL_STATUS=CLIENT_OR_SERVICE_INTERACTION_DEFECT_REMOTE_NOT_QUALIFIED

Evidence integrity notes

• Results were captured from one Android/Termux subject and bound to the stated runtime versions.
• The unsuccessful VPN-off probe artifact with stale modification time was excluded from causal conclusions.
• No 120-second stable remote-channel qualification or remote pwd succeeded because startup stopped before authentication.
• Raw logs should be reviewed locally for secrets before any upstream attachment; this report is the sanitized attachment candidate.