Redock vs Happy

Happy and Redock address the same modern problem: a coding agent can work for a long time, then stop after five minutes because it needs approval, clarification, or a decision. Both products let a developer leave the desk without abandoning that loop. Both can surface the session on a phone, accept a response, and keep the work moving.

Happy solves the problem with an agent companion. A CLI runs beside the agent on your computer, encrypts session updates, and synchronizes them through a relay to the phone or web client. The mobile interface renders the agent conversation rather than a general terminal. That focus makes the setup fast and the UI readable.

Redock solves the problem from the terminal side. It connects to the development machine through SSH or Mosh and treats the agent as a program inside a normal shell and persistent tmux session. Projects, Actions, Runs, Activity, and staged input add structure, but the underlying terminal remains available whenever the agent is not enough.

Happy’s strongest argument is simplicity. Install the CLI, pair a device, and the agent session becomes readable on iOS, Android, or the web. There is no SSH host record to create, no private key to import, and no terminal layout to learn. For someone whose only mobile requirement is “tell me when the agent needs me and let me answer,” that is the shortest path.

The product is also open source and designed around end-to-end encryption. Session data is encrypted on the computer, the relay stores or transports ciphertext, and the paired phone decrypts it locally. The default hosted relay is convenient, while a self-hosted deployment gives users control over that middle layer. This is a strong, principled model for a tool that sees sensitive prompts and code context.

Happy’s conversation-oriented UI can be easier to read than a terminal TUI on a phone. Markdown, code blocks, diffs, questions, and approvals can be presented as mobile interface elements rather than terminal cells. Parallel sessions, notifications, voice interaction, and desktop-to-phone handoff all reinforce the idea that the agent conversation is the complete job.

Happy is intentionally not a general terminal. That keeps the interface clean, but it creates a boundary. If the agent finishes and you want to tail a log, inspect a process, run psql, open lazygit, restart a service, change a file in Vim, or SSH to another machine, you need a separate terminal path.

Redock keeps that path in the same workspace. The agent runs inside the Shell, so a developer can interrupt it, execute an ordinary command, use a TUI, inspect the host, and then return to the agent. A named Action can capture a repeated task such as test, build, lint, migration check, or deploy without turning every operation into a fresh natural-language prompt.

This distinction matters less when the agent truly covers everything. It matters more in production-like development where the agent’s output must be verified with tools it did not choose. Redock’s terminal foundation creates a manual fallback and a place for deterministic commands; Happy optimizes the cleaner case where the conversation itself is enough.

Happy continuity lives inside the Happy session. The companion CLI holds the relationship with the coding agent, encrypted updates move through the relay, and paired clients catch up. This enables a polished desktop-to-phone handoff and makes the history readable even when the phone was temporarily offline.

Redock continuity lives in standard terminal infrastructure. The agent runs inside tmux on the development host. A laptop terminal and Redock can attach to the same session, with the same process, pane, scrollback, working directory, and terminal state. Mosh improves the mobile network path, while tmux ensures the work survives when no client remains connected.

The difference is ownership of the live session. Happy owns the companion session and can make its chat presentation excellent. Redock relies on a normal host-side multiplexer that any compatible terminal can reattach to. Choose the first for seamless agent-client handoff; choose the second when interoperability with ordinary terminal tools is more important.

Happy’s hosted relay sits in the network path, but it is designed not to see plaintext. The computer and paired device hold the keys, while the service handles encrypted blobs. Users who do not want the hosted service can self-host the server. This model makes connectivity convenient without exposing session content to the operator when implemented as documented.

Redock connects directly to the user’s development host over SSH or Mosh. The terminal data path does not require a Redock session relay. That approach fits developers who already have SSH access through a public endpoint, VPN, Tailscale, or another private network and want the mobile client to behave like a standard terminal.

Neither architecture is automatically more secure in every deployment. Happy reduces SSH setup and offers application-level end-to-end encryption, but adds a companion process and relay service to understand. Redock uses well-known remote-shell infrastructure, but the user must secure network reachability, keys, host verification, and server configuration. The right choice follows your existing threat model and operational comfort.

Happy’s primary unit is a conversation. Redock’s primary unit is a Project that combines a host, repository directory, active terminal session, and the repeated commands associated with that codebase. This makes Redock more opinionated about what happens before and after a prompt.

Developer Actions are important because not every task should be delegated. Running the canonical test suite, checking formatting, building a preview, or deploying a known environment is often safer as an exact command. Redock can expose that command as a named control and preserve its Run output, reducing the need to ask an agent to reproduce a deterministic process.

Both products support voice-oriented interaction, but the experience follows their architecture. Happy can provide conversational voice with the agent. Redock uses voice as a staged requirement: dictate, inspect, edit, and send to the current terminal agent. Happy feels more like talking to a remote collaborator; Redock feels more like composing a precise instruction for a tool already running in the Project.

Happy is the honest winner when price, openness, easy pairing, web access, and a focused agent conversation are the priorities. It asks very little from the user and covers the interrupt-and-approve loop extremely well. If a terminal would only add clutter, paying for a broader workbench makes no sense.

Redock is the better fit when agent supervision repeatedly crosses into ordinary development operations. The ability to reattach to tmux, run an exact Action, inspect the host, switch to another shell tool, or return to Project Activity keeps the entire loop in one place.

Some developers may still use both: Happy for its readable cross-platform agent companion and Redock for direct SSH/Mosh work on the same machine. But because the products target such a similar moment, most people should first choose the architecture they trust and the boundary they want—conversation only, or conversation plus terminal.