[Bug]: iOS app lets a thread select Full access above a managed policy cap, then hangs retrying the refusal #32208

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/mobile

Steps to reproduce

1. Run a T3 server with a managed policy that sets limits.maxRuntimeMode: "auto", with defaultRuntimeMode set to auto and locked.
2. Pair the iOS app with that server and open a thread.
3. Select Full access in the mode picker.
4. Send a message in that thread.

This comes from one run. I haven't repeated it from a clean start, and my notes don't record which mode picker I used.

Expected behavior

Full access is greyed out with the policy's reason. If a change is refused anyway, the app says so, returns to the allowed mode, and the thread's messages still send.

Actual behavior

• Full access could be selected, and the app showed no refusal.
• The app kept sending the mode change. The server refused every attempt, about every 12–16 seconds while the app was open, for more than 35 minutes.
• No message.dispatch reached the server for the thread's messages, so the thread looked hung on pending.
• Setting the mode back and force-quitting did not clearly clear one thread, although the order of those steps wasn't recorded.

The cap itself held. Nothing ran in Full access, and the Claude processes ran with --permission-mode auto.

Impact

Minor bug or occasional failure

Version or commit

iOS app 2.2.0, server t3@0.1.7

Environment

Server on Linux, reached over Tailscale Serve, with the Claude provider.

Logs or stack traces

thread.runtime-mode.set refused: "<organization> limits threads to Auto."

Workaround

Archive the thread, which stops the retries, and start a new one. New threads worked normally.

Additional context

Two things I couldn't determine:

• Why the option was selectable. At the v0.1.7 tag, ThreadSettingsSheet.tsx passes config?.managedPolicy to withManagedRuntimeModeLimits and disables the rows above the cap, so this should have been greyed out. The server sends managedPolicy in its config. The installed app build may differ from that tag, or another path may skip the limit.
• What retries the command. I didn't trace it.

The closest existing reports, #29632 and #22957, describe different failures.

Drafted with Claude Code from my notes on the run, and reviewed by me.