What the daemon exposes beyond chat relay

[seth-with-zest]

Short version: The Happy daemon registers RPC handlers that give the relay server shell execution, file I/O, and filesystem browsing on your machine. Chat uses a separate channel and works without them. Users who only use the chat interface are carrying attack surface they don't need.

---

What I found

I use Happy as a chat interface to Claude Code from my phone. While checking whether my install was up to date, I had Claude Code audit the happy-coder package. The finding: the daemon registers 7 RPC handlers that the relay server (api.cluster-fluster.com) can invoke on any connected machine.

Handler	Capability
bash	Arbitrary shell command execution via exec()
readFile	Read files within working directory (base64)
writeFile	Write files with conflict detection
listDirectory	Directory listing with metadata
getDirectoryTree	Recursive directory traversal
ripgrep	Code search
difftastic	Structural diffs

These handlers are registered on the daemon side regardless of whether the mobile app's current UI exposes all of them. The app source in the monorepo has call sites for bash (git status, CLI detection), readFile (file viewing), and ripgrep (file search autocomplete). Three handlers (writeFile, listDirectory, getDirectoryTree) are exported but never called. difftastic is never called as an RPC.

The commands are relayed through the Happy server — the app sends an RPC request, the server forwards it, the daemon executes it locally. Payloads are encrypted (NaCl/AES-256-GCM), but the server facilitates the key exchange.

The chat relay (sendClaudeSessionMessage) is a completely separate code path. Disabling all 7 handlers has no effect on sending or receiving messages.

Trust model

Running the Happy daemon means trusting the relay server with command execution on your machine. That's inherent to how the remote features work. The bash handler validates cwd against the working directory, but the command itself is unrestricted — any shell command is accepted.

I may be missing context for why the architecture works this way — there could be good reasons I don't appreciate. But the surface area seems worth understanding regardless.

Disabling the handlers

Working with Claude Code, I put together a patch script that injects rejection stubs at the end of registerCommonHandlers(), overwriting the original handlers via Map.set() semantics. All 7 handlers return { success: false, error: "Handler disabled" }.

After auditing the app source (packages/happy-app/sources/):

• Every RPC wrapper catches errors and returns a structured failure — no crashes, no hangs
• No handler failure can block chat, navigation, or message sending
• The app degrades gracefully: features that depend on the disabled handlers show empty states or placeholders

The patch must be reapplied after npm update since it modifies build artifacts. I run it as part of a nightly update job. Happy to share the script if useful.

Other findings

• ~/.happy/access.key is created with 644 permissions. Contains the JWT auth token and NaCl keys. Should be 600.
• ~/.happy/logs/ stores decrypted conversation content in plaintext with no rotation. Accumulated ~1GB over 5 weeks.
• Session metadata sent to the server includes the full list of MCP tools, slash command names, working directory paths, hostname, and home directory.

Suggestions

1. Document the trust model. Users should know that the daemon grants the server command execution access.
2. Add a chat-only config flag that disables direct-access handlers. The app already handles all failures gracefully.
3. Create ~/.happy/access.key with 600 permissions.
4. Add log rotation for ~/.happy/logs/, or document that conversations are stored locally in plaintext.
5. Consider a bash allowlist. The app source sends a small, predictable set of commands (git status, git diff, command -v, env var echo). An allowlist would preserve those features while closing arbitrary execution.