v0.63.12: 401/session fix from #5307 landed, but realtime socket between desktop client and remote headless core still broken

[Jasonsun77]

Summary

On v0.63.12, the session 401 regression from #5307 is fixed — auth_store_session succeeds, backend calls (team_get_usage, billing_get_current_plan, orchestration/v1/sessions) all return 200, and signed_out stops flipping. However, the realtime Socket.IO channel between the desktop client and a remote headless core remains broken. The desktop client shows "Disconnected" / "Realtime socket is not connected - responses cannot be delivered without a client ID." and chat is completely non-functional.

Environment

• Core: openhuman-core serve v0.63.12, headless on Ubuntu 26.04 (systemd), x86_64
• Desktop client: v0.63.12, Windows, connected via Advanced → remote core RPC URL (http://<host>:7788)
• Provider: NVIDIA (stepfun-ai/step-3.7-flash), configured and validated

What works after upgrading to v0.63.12

• openhuman.auth_store_session → ok (session JWT stored, expiry 2026-11-05)
• All HTTP JSON-RPC calls from desktop → core succeed (core.ping, threads_list, inference_get_client_config, threads_messages_list, etc.)
• Core → backend Socket.IO (wss://api.tinyhumans.ai) connects successfully: Server ready - auth successful
• No more 401 errors in journalctl
• scheduler_gate signed_out stops flipping after session is stored

What does NOT work

• Desktop client shows "Disconnected" / "Realtime socket is not connected - responses cannot be delivered without a client ID."
• Sending a chat message is impossible — the orchestration layer requires a realtime client ID that never gets established
• The desktop client's Socket.IO connection to the remote core never upgrades from polling to websocket

Diagnosis

From the core side (journalctl), after auth_store_session succeeds:

[socket] Session token found - auto-connecting to https://api.tinyhumans.ai
[socket] WebSocket connected, starting handshake
[socket] SIO CONNECT ACK
[socket] Server ready - auth successful
[medulla] advertising 38 agents to backend

The core's own socket to the backend is healthy. The problem is the desktop → core Socket.IO channel:

1. curl http://<core-host>:7788/socket.io/?EIO=4&transport=polling from the desktop machine returns a valid Engine.IO handshake (0{"sid":"...","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":20000})
2. HTTP JSON-RPC over /rpc works perfectly (all calls return ok)
3. But the desktop client's Socket.IO never establishes a connected session with the remote core — it stays in "disconnected" state

This suggests the desktop client's realtime socket implementation has a regression specific to the remote core mode — it does not properly complete the Socket.IO handshake with a non-local core, even though polling transport is reachable and the HTTP RPC layer is fully functional.

Comparison with #5307

Symptom	v0.63.9	v0.63.12
401 on backend auth calls	Yes	Fixed
auth_store_session	Fails	Succeeds
HTTP RPC (desktop → core)	Works	Works
Core → backend Socket.IO	Fails	Works
Desktop → core realtime socket	Broken	Still broken
Chat functional	No	No

Impact

The remote-headless-core deployment path remains entirely unusable on v0.63.12. This affects users running openhuman-core serve on a dedicated server/NAS/homelab and connecting from a desktop client on another machine.

Request

• Reopen 0.63.9: backend rejects session token on GET /auth/me → forced logout loop (TAURI-RUST-RYD, 21 users) #5307 or track this as a follow-up: the auth/session fix was necessary but not sufficient for the remote core use case
• Investigate the desktop client's Socket.IO connection path when OPENHUMAN_CORE_RPC_URL points to a remote host — specifically why the polling handshake succeeds but the realtime channel never activates
• A workaround or flag to force Socket.IO transport would be helpful