I keep ending up with the same awkward situation:

I’ve got multiple sessions going (Claude Code, Codex, OpenCode). I put my laptop down for a bit. I come back and something feels off.

Not “it crashed” — more like:

• nothing is moving
• the output stopped mid-thought
• the session is “running” but I’m not sure it’s doing anything

The worst part is the overhead: if you have 5–10 sessions, you can burn 20 minutes just figuring out which one needs attention.

This guide is the workflow I use to answer one question quickly:

Which session is actually stuck, and what kind of stuck is it?

TL;DR

1. Don’t guess. First classify the stuckness:
   • Waiting for approval / needs input (the common case)
   • Disconnected / offline (machine sleeps, Wi‑Fi dropped)
   • Busy (still running, just slow)
   • Broken (crashed / wedged)
2. Start with the lowest-friction checks (session list + last activity + one log tail).
3. If you want a phone-friendly “what needs attention right now?” loop, Happier is one of the options that helps because it has a global Inbox and notification routing for requests.

The problem (in plain language)

Most “stuck sessions” are not actually stuck.

They’re waiting.

• waiting for a permission prompt
• waiting for a question you didn’t answer
• waiting because your laptop slept and the client is disconnected

The reason this is hard is that terminals don’t tell you “this needs your attention.” They tell you “this process exists.”

And if you have multiple sessions, the cost isn’t the fix — it’s the diagnosis.

What I tried first (and where I bounced off)

• Just keep fewer sessions: realistic sometimes, but I still end up parallelizing when I’m doing real work.
• One tmux window per repo with a naming scheme: helps, but it’s still a manual scan.
• Tail logs (Codex log_dir / OpenCode logs): useful, but you still have to open the right one.
• Claude Code’s built-in resume/naming and Agent Teams view: useful, but it doesn’t give me a cross-provider “attention list”.

Happier is one of the tools I use when I want that “attention list” behavior from my phone (or browser), because it surfaces approvals/requests in one place.

If you’re new to Happier (what it is, and where to get it)

If you haven’t seen Happier before: it’s an open-source companion app (mobile/web/desktop) for coding sessions like Claude Code, Codex, and OpenCode.

The workflow is: sessions keep running on a machine you trust (laptop / server / dev box), and Happier is where you monitor, approve, and keep things moving from your phone.

Get set up:

• How to run Happier from your phone
• GitHub: https://github.com/happier-dev/happier
• Install/download: https://github.com/happier-dev/happier#how-it-works
• Discord: https://discord.gg/W6Pb8KuHfg

A diagnostic checklist that works

1) First: is it waiting for you?

If the session is “stuck”, I ask: is it actually blocked on a human decision?

Common signs:

• the last output is a question ("Which option should I pick?")
• the session is waiting on tool permissions
• the session is in a provider-specific mode that requires a user action (e.g. exit plan)

If you’re using Happier, this is where the global Inbox helps: approval requests and permission/user-action requests surface there, and notification routing tries to land you in the exact session that needs attention.

2) Second: is the client disconnected because the machine slept or Wi‑Fi dropped?

If you closed a laptop lid, hopped networks, or your client went into background, the process might be fine but your view is stale.

Typical fixes depend on your tool:

• If you are SSH’ing, Mosh is the least painful “roaming + sleep” upgrade for this class of problem.
• If the tool is a client/server streaming UI, you may need to reconnect or reload the stream.

(There are real-world reports of “stale session state after sleep” issues in client/server tools; in those cases the fix is often “reconnect + upgrade”.)

3) Third: is it busy, just slow?

A session can look stuck when it’s:

• chewing through a big diff
• running tests
• waiting on a slow network call

In this case, what you want is progress signals:

• last tool call timestamp
• last file edit
• last token output

If you can’t get any progress signal, treat it as broken and move to the next step.

4) Last: treat it as wedged (and choose a safe intervention)

If you’re convinced it’s truly wedged:

• prefer a low-risk interrupt (“stop and summarize where you are”)
• then restart/resume

Avoid killing processes blindly if you care about preserving session identity. If you have a resumable model, use resume/attach paths rather than “start new and paste context”.

A phone-first “attention list” workflow (Happier)

If you’re running many sessions and you keep losing time to diagnosis, the best thing Happier gives you is not “more power.”

It’s less searching:

• Inbox answers: “what needs my attention right now?”
• Notifications deep-link to the right session (and the right server profile)

The honest trade-off: it depends on the machine still being reachable.

Troubleshooting

I can’t tell if it’s stuck or waiting

Force a decision:

• send a short message: “Are you waiting on my input or still running?”
• if the tool supports it, request a one-line status update

I keep losing track of sessions

Use one of these patterns:

• one worktree / one session per task
• consistent naming for sessions and repos
• one “attention list” surface (Inbox / notifications)

Related guides

• How to monitor Claude Code from your phone
• How to resume AI coding sessions from your phone
• How to queue messages from your phone while an agent is busy