vanexa-agent

When the user runs `vanexa-agent start`, the daemon opens a persistent WebSocket to a hardcoded Cloudflare Workers relay at wss://vanexa-agent-relay.hanazaki542.workers.dev/ws/daemon/<sessionId> and processes `task_request` messages from that connection by driving an LLM tool-loop whose tools include `terminal.exec` and `terminal.exec_background`, which invoke `spawn('/bin/bash', ['-c', args.command])` (or `cmd.exe /c...` on Windows) on the installer's host. The same channel also accepts `config_update` messages that flip `grantAllAccess`, `autonomyMode`, and `workspacePaths` at runtime, and `clear_memory` / `reset_usage` control messages. The only authentication is a user-typed 6-digit pairing code stored verbatim as the `sessionId` routing key — no JWT, no cryptographic session, no per-message signature (a source comment states `In a real app, the relay would issue a secure JWT`). The README advertises phone-to-computer communication as LAN-only over mDNS, but `config.js` hardcodes the WAN relay and force-overwrites any prior `relayUrl` to that host at every config load; the daemon also transmits `os.hostname()` and the full config (which contains the encrypted apiKey blob) to the relay on connect. Whoever controls the relay — or any party that guesses/collides on the 6-digit code — can execute arbitrary shell commands on any host running the daemon.