codex hangs

[jerodvenemafm]

Starting a session from codex on macos (latest codex build) just hangs on "waiting for messages".

[jerodvenemafm]

I can run commands from my phone, just not from the terminal.

[jerodvenemafm]

Claude works great, btw. Love this app.

[alecgorge]

i have the same issue where i can run commands from my phone but not from my laptop for codex. i also cannot resume a codex session that was started with happy for some reason

[WilliamKeating]

I'm having the same issue as well. The first time I used Happy with Codex it was working properly and now when I run Happy Codex it won't let me interact locally.

[leeroybrun]

Hi,

I can confirm this is expected behavior based on how Codex is currently implemented. Codex in Happy can only be used through the UI currently (mobile/phone or https://app.happy.engineering/ from your computer) and not from the terminal.

The key difference:

With happy, (claude) we're able to leverage the existing Claude Code TUI directly. The CLI spawns Claude Code with inherited stdio, so all the interactive terminal functionality comes from Claude Code itself; we're essentially just wrapping it.

With happy codex, it's different. Codex is integrated via MCP (Model Context Protocol) as a programmatic client. The Codex CLI doesn't provide an interactive TUI like Claude Code does, it's designed for MCP-based communication. The "Waiting for messages..." screen is intentional: it's waiting for input from the Happy app/web interface.

We can definitely make it clearer in the happy codex terminal UI though, as I was surprised by this at first too and had to dig into the code to understand why it did not work like happy(claude).

Why local mode isn't implemented for Codex:

Implementing local terminal input for Codex would require building a complete TUI from scratch, since there's no existing interactive interface to wrap (unlike Claude Code). This is a significant undertaking compared to the Claude integration.

[alecgorge]

no worries. that makes sense, and i'm fine to use it that way--it was just unclear based on the pitch on the marketing pages.

is this because claude is a bun/ts implementation so it can be monkeypatched around whereas codex is a rust binary?

[JustinZhang6]

It’s honestly sad Happy Codex doesn’t support that

[leeroybrun]

is this because claude is a bun/ts implementation so it can be monkeypatched around whereas codex is a rust binary?

Not exactly TS vs Rust: Claude Code has two things Happy can rely on: (1) an interactive TUI we can spawn with inherited stdio, and (2) supported plumbing to track/resume sessions.

When you start happy in the terminal, it starts the real claude process, and it gets the session id via a hook. It then mirrors output to the Happy UI by tailing Claude’s JSONL logs. At that time, you interact directly with Claude Code in the terminal, happy-cli just streams the logs to Happy UI. When you want to interact from the app, happy-cli switches to the Claude SDK instead (it kills the interactive claude TUI process + stops JSONL scanner + spawns a new Claude Code process in headless/stream-json mode (via the SDK runner) and resumes the conversation using the session ID captured from the SessionStart hook).

When you interact again with the terminal, happy-cli stops the SDK‑spawned Claude process, and then launches a new claude process passing --resume <sessionId> + starts streaming JSONL again for UI.

Codex is different: the local Codex TUI doesn’t currently expose Claude-like hooks (see openai/codex#2109), and the MCP interface doesn’t reliably support resuming an on-disk rollout across restarts the way codex resume <id> does (see openai/codex#6168). I had a PR ready to add durable resume support to the Codex MCP (see openai/codex#8689), but they’re currently only accepting bugfixes, no feature/enhancement PRs, and they categorized this as an enhancement.

Without those two pieces, Happy can’t implement the same “local TUI + seamless local <-> remote switching” flow reliably for Codex, unfortunately.

[shayne]

I've created a fork where I'm fixing Codex related issues https://github.com/shayne/happy

On npm it's happy-codex and you can just npx -y happy-codex@latest to start a new session

[leeroybrun]

@shayne awesome! would encourage you to propose changes to the main happy repo if you have some good ideas. This would prevent splitting the project even more than it already is. We have a big new release incoming with a lot of changes, fixes, and new features, including a lot of fixes for Codex already applied to it: #487

I know we have not been very active lately, deeply sorry for that, but we are back and would love to have your contributions and ideas so Happy can continue thriving and be the best version it can be with everyone's contributions :)

[shayne]

Sure thing. I’ll aubmit upstream. I needed to unblock myself in the meantime. On Jan 28, 2026, at 04:52, Leeroy Brun ***@***.***> wrote:leeroybrun left a comment (slopus/happy#358) @shayne awesome! would encourage you to propose changes to the main happy repo if you have some good ideas. This would prevent splitting the project even more than it already is. We have a big new release incoming with a lot of changes, fixes, and new features, including a lot of fixes for Codex: #487 I know we have not been very active lately, deeply sorry for that, but we are back and would love to have your contributions and ideas so Happy can continue thriving and be the best version it can be with everyone's contributions :) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[leeroybrun]

In case anyone is interested, might have a Codex remote/local switching soon in https://github.com/happier-dev/happier (wasn't able to contribute upstream after all, so created my own fork with all the changes from #487 and more)