iOS App: reply body text never displayed (title updates work, mobile Safari works)
Summary
iPhone Happy App shows conversation titles updating correctly but never renders the reply body text. The same account on mobile Safari (app.happy.engineering) displays replies normally — confirming the issue is in the iOS App's message rendering layer, not the backend.
Environment
- Happy CLI:
1.1.0-2 - Mac: Mac mini, macOS Darwin arm64
- iPhone: iOS (latest)
- Mac hostname:
lyrikdeMac-mini.local
Steps to Reproduce
- Authenticate and start daemon on Mac (
happy daemon start) - Open Happy iOS App, connect to the Mac device
- Start a new conversation from the iPhone App
- Send any message (e.g., "test")
- Observe: title updates but reply body is not displayed
- Open
https://app.happy.engineeringin mobile Safari on the same iPhone - Send the same message → reply body displays correctly
Expected Behavior
Reply body text should be displayed in the iOS App, same as it appears in the web interface.
Actual Behavior
- Title/metadata updates: visible in iOS App
- Reply body text: never displayed in iOS App
- Push notifications: received successfully
- Mobile Safari (same device, same account): works correctly
Diagnostic Evidence
Mac-side logs confirm the full pipeline succeeds every time:
[10:39:43] Title changed (happyMCP title update succeeded)
[10:39:44] Final answer generated (phase: final_answer)
[10:39:45] Push notifications sent successfully (1 token)
[10:39:46] new-message (t: encrypted) seq 3-5 sent via socket
[10:39:47] ev.text + turn-end + ready events all delivered to serverNo errors, disconnects, or failures in any daemon or session log.
What We've Already Ruled Out
| Hypothesis | Action Taken | Result |
|---|---|---|
| Stale daemon / zombie processes | Killed 87 old processes, clean restart | Same issue |
| Credential / machine ID corruption | happy auth login --force x3 (3 different machine IDs) |
Same issue |
Old happy-coder vs new happy conflict |
Removed all old version processes | Same issue |
onboardingCompleted: false |
Fixed to true |
Same issue |
| WebSocket disconnection | Clean daemon, verified stable connection | Same issue |
| Server-side message delivery | Logs show encrypted messages + events fully delivered | Confirmed working |
| Mobile Safari on same iPhone | Tested — replies display correctly | Confirms iOS App bug |
Conclusion
The issue is isolated to the iOS App's handling of new-message events with t: encrypted content type. The App correctly processes update-session.metadata (title updates) but fails to decrypt or render the message body from new-message payloads. All server-side evidence confirms successful delivery.
The critical proof: same iPhone, same account, same Mac daemon — mobile Safari shows replies, iOS App does not.
Source: slopus/happy