Model or dataset
happier-dev/happier avatar
happier-dev/happier

Happier: an end-to-end encrypted remote client for local AI coding agents

Web, Desktop & Mobile client for Codex, Claude Code, OpenCode, Kimi, Augment Code, Qwen, fully end-to-end encrypted

1,669 stars145 forksTypeScriptMIT

At a glance

What is it?
Happier wraps Claude Code, Codex, OpenCode and other CLI agents so a session running on your machine can be followed and controlled from a phone, browser or desktop app. The README is explicit that this is alpha software, and the provider list is wider than the documentation behind it.
Who is it for?
Adopt Happier if you already run Claude Code, Codex or OpenCode locally and want to check on a session from a phone without leaving your machine as the execution host. Do not adopt it if you need stable interfaces, published security documentation, or a provider matrix with per-provider support notes, because none of that is in the material.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 1 day ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The gap Happier is trying to close between a terminal agent and a phone

A coding agent CLI is tied to the machine it runs on and to the terminal window that started it. Step away and the session is still alive, but you cannot see it, answer a permission prompt, or redirect it. Happier's stated purpose is to keep that session local while making it reachable from another device: the README describes it as a companion app that lets you "run AI coding sessions locally on your computer, then continue and control them remotely." The execution host does not move. Only the control surface does.

The intended user is someone who already runs one of these agents daily and treats the terminal as the primary interface. The README says the project "exists because we needed it ourselves," and the origin story is that the maintainers were contributors to Happy (slopus/happy) before forking off to iterate faster on their own needs. That matters for expectations: Happier is a derivative of an existing tool, not a first attempt at the problem. It also means the feature list reflects one team's daily workflow rather than a general roadmap.

The project is TypeScript, MIT licensed, on the dev branch, and the README states plainly that it is "in alpha preview stage and might be buggy here and there." That sentence should set the bar for everything below.

How the CLI wrapper, the provider CLIs and the encrypted relay fit together

The mechanism is a substitution at the command line. Where you would type `claude`, you type `happier`. Where you would type `codex`, you type `happier codex`. The README's Step 4 lists `happier`, `happier codex`, `happier opencode`, `happier gemini`, `happier kilo`, `happier kimi` and `happier qwen` as the invocation forms. So Happier sits in front of the provider CLI rather than reimplementing it, and the provider keeps doing the actual work on your machine.

Around that wrapper sits the cross-device layer. The README describes Happier as "a secure bridge between your local development environment and your other devices," and the headline property is end-to-end encryption. The authentication flow is mobile-first by design: `happier auth login` asks which device should hold the account, and the README recommends choosing mobile so that "your account and secret key are then securely stored on your mobile device." That tells you where the key material is expected to live, and it tells you what to think about before running the command on a shared or borrowed machine.

The session model is the other half of the architecture. Sessions are persistent and can be resumed after restarts, archived and reopened. They can be attached to from either direction: start in the app and reconnect from the terminal with `happier attach`, or start in the terminal and pick it up in the app. The README also describes browsing and taking over sessions that were started outside Happier, including following a live session in real time. For forking, the README states that provider-native forking is used where available (it names OpenCode and Codex) and that a fallback called Happier Replay covers the rest. That fallback is the interesting part, because it implies a reimplementation of session state rather than a passthrough, and the README does not describe how faithful the replay is.

Install commands, auth, and the attach workflow you actually type

The install path is a shell script on macOS and Linux: `curl -fsSL https://happier.dev/install | bash`. Windows uses PowerShell: `iwr https://happier.dev/install.ps1 -useb | iex`. The README notes that if you specifically want the npm package rather than the installer-managed lanes, you can run `npm install -g @happier-dev/cli`. The phrase "installer-managed lanes" is doing real work there: it implies the curl installer manages more than a binary, and the npm route is a different track with potentially different update behaviour. The README does not spell out the difference, so if you care about how updates arrive, that is a question to resolve before choosing a lane.

Authentication is one command, `happier auth login`, and the README recommends mobile as the device that holds the account and secret key on first run. There is also a terminal-connect link flow: if you open that link while logged out, the README says Happier sends you through sign in or account creation and then returns you to terminal approval.

Mobile clients come from three places. iOS is on the App Store under the name "Happier - Claude Codex Opencode." Android is in private beta, and the README gives the exact steps: join the Happier Google Group, then join the beta either from Android or from the web at the Play Store testing URL. There is also a direct APK download from the `ui-mobile-preview` release tag for people who do not want the Play Store route.

Once running, the daily commands are the provider invocations plus `happier attach` for reconnecting a terminal to a session that the app is driving. The README describes this as switching "between local CLI control and remote app control at any time."

Where the README stops short: provider matrix, replay fidelity and security detail

The provider list is the widest claim in the README and the least documented. The Key Features section names Claude Code, Codex, OpenCode, Gemini, GitHub Copilot, Kiro, Pi, Kilo, Kimi, Qwen, Augment, and "any custom ACP-compatible CLI." The install section demonstrates seven of them. The repository description mentions Codex, Claude Code, OpenCode, Kimi, Augment Code and Qwen. The hero image alt text lists Claude Code, Codex, OpenCode, Pi and Cursor. Four different lists in one README is not a documentation style choice; it is a sign that provider support is uneven and that the matrix is not maintained. If your agent is not in the Step 4 command list, treat its support as unverified and test it before building a workflow on it.

End-to-end encryption is the headline property and there is no design document in the supplied material. The README does not describe the key exchange, what the server can see, how device revocation works, or what happens when you lose the device holding the secret key. Mobile-first key storage makes that last question concrete: if the secret key lives on your phone and the phone is gone, the README's account recovery story is not stated. That is not a flaw in the product, it is a gap in what a prospective user can evaluate from the repository front page.

The alpha label is stated twice and should be taken literally. The README says the project "might be buggy here and there" and that the team is "iterating fast." The release tags in the repository reflect that: `ui-web-v0.2.12-dev.319` is a dev build with a build number in the hundreds, `ui-web-dev` is a rolling tag, and `ui-mobile-dev` last moved in March 2026 while the web bundle moved in September 2026. Mobile and web are not shipping on the same cadence, and the version numbers are pre-1.0 development builds rather than stable releases.

The honest comparison is with Happy, the project Happier forked from

The README names the alternative itself. Happier began as contributions to Happy (slopus/happy), and the maintainers say they "realized that our own needs required faster iteration that we could not comfortably explore within the main project." The difference in approach is governance and pace, not architecture. Both wrap local agent CLIs and both target cross-device continuation. Happier's stated bet is that moving faster on features the maintainers personally want is worth diverging from the upstream project they still describe as a foundation they are "deeply grateful for."

If you are choosing between them, the practical question is which one covers your provider and your device today, and which one you can read the source of when something breaks. Happier's differentiators per the README are the breadth of the provider list, session handoff between machines (the README says the same session ID stays in place and only the active machine changes), collaborative sessions with view-only public links, and an Agents panel for subagents and Claude teams. Happy's advantage is that it is the more established codebase with a longer history, which for a tool that holds credentials and drives an agent on your machine is not a trivial consideration.

A second alternative worth naming is not using a companion app at all: run the agent inside tmux on the host and reconnect over SSH. That gives you session persistence and remote access with no new trust boundary, at the cost of no mobile UI, no push notifications and no shared sessions. Happier's value proposition is exactly the part tmux cannot give you.

Collaboration, subagents and the voice agent: features that widen the surface

Beyond remote control, the README lists collaborative sessions: you can share a live session with teammates, add friends by username inside the app, or publish a view-only public link. It also documents session handoff between machines, where a live session including provider state and project directory moves to another host while keeping the same session ID. That is a stronger claim than remote viewing, because it means the tool is relocating state that the provider CLI owns, and the README does not explain what happens to an in-flight tool call during the move.

The Agents panel manages subagents and Claude teams: launching parallel review, plan or delegate runs, creating teams, messaging individual teammates, and monitoring subagents in one place. The voice assistant is described as "a first-class assistant backed by the same action system as the UI and CLI," which monitors running sessions and can switch focus between them. That is a meaningfully different claim from speech-to-text, and it is also the feature most likely to be unfinished, since the README's own text on it is truncated mid-sentence in the supplied material.

Every one of these features increases the number of paths that can act on your machine. Collaborative sessions mean another person's client can drive an agent in your project directory. Session handoff means provider state moves between hosts. The README does not document permission boundaries for shared sessions, which is the thing to test before inviting anyone.

Maintenance cost, licence and what to check before depending on it

MIT licensing means you can read, modify and redistribute the code, including in commercial settings, subject to the licence terms. It says nothing about the hosted components. The README describes a self-hostable product and a homepage at happier.dev, but it does not draw the line between what runs on your machine, what runs on the relay, and what the hosted service does with metadata. If you need that boundary documented before adoption, the supplied material does not provide it.

Upgrade cost is shaped by the release lanes. The curl and PowerShell installers are described as managing lanes, and the npm package is presented as the alternative for people who want npm. Mixing them is the obvious way to end up with two copies of the CLI. The dev tags (`ui-web-dev`, `ui-mobile-dev`, and the numbered `ui-web-v0.2.12-dev.319` build) suggest the project ships development builds continuously, so pinning a version and reading release notes before moving is the only way to keep behaviour stable. The README does not describe a stable channel.

The practical pre-adoption checklist is short and specific. Confirm your provider is in the `happier` subcommand list, not just the feature list. Run `happier auth login` somewhere disposable and note where the secret key is stored and what recovery looks like if that device is lost. Start one session with `happier` in a scratch repository and confirm `happier attach` reconnects to it from a second terminal before trusting it with a real project. Then decide whether the alpha label is acceptable for the work you have in mind.

Editorial conclusion

Adopt Happier if you already run Claude Code, Codex or OpenCode locally and want to check on a session from a phone without leaving your machine as the execution host. Do not adopt it if you need stable interfaces, published security documentation, or a provider matrix with per-provider support notes, because none of that is in the material. Verify first: run `happier auth login` on a spare machine and confirm where the secret key lands, then check whether your specific provider appears in `happier --help` rather than only in the README feature list.

Official sources

  1. happier-dev/happier on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
Community notes

Community notes