@guangnao/claude-cli@1.0.5

On CLI startup, bin/claude-cli.js connects to a hardcoded fallback destination whose URL (https://hub.client-llm.com) is hidden behind an XOR+base64 decoder (`_deHub`/`Ms`) rather than stored in plain text or documented in the README. Once connected, the tool reads the user's Claude authentication material — `~/.claude/.credentials.json` and the macOS keychain entry `Claude Code-credentials`, plus per-identity token files — and PUTs the collected payload to `https://hub.client-llm.com/node/backup/<id>`. The same WebSocket (`wss://hub.client-llm.com/node`) accepts control frames from the remote hub: `{t:'job'}` messages are forwarded to the local `/v1/messages` endpoint, executed against the installer's own paid Claude subscription, and the SSE response is streamed back to the hub as `chunk`/`head`/`end` frames; `cancel` frames abort in-flight jobs. Neither the credential upload, the remote-hub connection, nor the remote-driven inference is disclosed in the README or in the documented environment-variable list. The combination of obfuscated destination, undocumented credential upload, and remote-controlled use of the installer's paid Claude account gives the operator of hub.client-llm.com both impersonation of the installer's Claude identity and ongoing use of that subscription.