[BUG] Permission prompts go unresponsive around usage-limit-reached in remote-attached --rc tmux sessions; occasional unexplained agent stalls (Ctrl+C sometimes recovers) Environment

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title: [BUG] Permission prompts go unresponsive around usage-limit-reached in remote-attached --rc tmux sessions; occasional unexplained agent stalls (Ctrl+C sometimes recovers)
Environment

Related/possibly-related issues: #52084 (phone approval hangs host), #28508 (mobile selections not received by CLI, also tmux), #35637 (prompts don't render on mobile), #34255 (silent connection drop, no recovery). This report differs in that the unresponsiveness clusters specifically around usage-limit-reached, occurs on both the mobile app and Desktop, and prevents opting into available extra-usage budget (Pro plan).

Claude Code version: 2.1.159
Server OS: Linux (session running in tmux via claude --rc)
Remote clients affected (both):

Claude mobile app — Android (Samsung S22+, app updated 2026-05-29)
Claude Desktop — 1.9659.0 (2026-05-28)

Description
A Claude Code session runs on a Linux server inside tmux (claude --rc), attached remotely from either the Claude mobile app or Claude Desktop. Two related symptoms occur:

1. Permission prompts unresponsive around usage limit (primary)

Under normal conditions permission prompts work fine from the remote client. However, around the point where the usage limit is reached, the prompts frequently become unresponsive — the session blocks and the prompt/limit notice cannot be acted on from the remote side. Recovery generally requires returning to the local machine, effectively forcing a manual restart.

1. Occasional unexplained agent stall (secondary)

Separately and less frequently, the agent simply stops responding mid-session with no visible cause (no error, no prompt). A careful Ctrl+C in the terminal session sometimes unblocks it and lets the agent continue — suggesting the agent is stuck in a waiting/blocked state rather than crashed.
Because both symptoms appear on the mobile app and on Desktop, they seem tied to remote-attaching to the --rc session rather than to a specific client platform.
Steps to reproduce

What Should Happen?

Permission prompts and usage-limit blocks remain interactive from a remotely-attached client, and the agent does not stall without surfacing an error, so the session can continue without physical access to the local machine.
Actual behavior
Around usage-limit-reached, permission prompts stop responding and the session blocks; recovery typically requires the local terminal. Independently, the agent occasionally stops responding with no visible reason, sometimes recoverable via a careful Ctrl+C in the terminal.
Impact / workaround
The point of attaching from a phone or second machine is to keep a long-running session going without being at the server; these stalls remove that benefit. Workarounds: returning to the local machine (for the limit case), or a careful Ctrl+C in the terminal (sometimes recovers the unexplained stall).

Error Messages/Logs

Steps to Reproduce

Start a Claude Code session on the Linux server in tmux: claude --rc.
Remote-attach from the Claude mobile app or Claude Desktop.
Run work until the usage limit is reached (or, less predictably, until the agent stalls on its own).
Attempt to act on the permission prompt / continue the session from the remote client.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.159

Platform

Anthropic API

Operating System

Linux Ubuntu 24.04

Terminal/Shell

Additional Information

Related/possibly-related issues: #52084 (phone approval hangs host), #28508 (mobile selections not received by CLI, also tmux), #35637 (prompts don't render on mobile), #34255 (silent connection drop, no recovery). This report differs in that the unresponsiveness clusters specifically around usage-limit-reached, occurs on both the mobile app and Desktop, and prevents opting into available extra-usage budget (Pro plan).