Language
Network checklist
Not applicable: the phone can reach Relay through the configured tunnel and load thread content. These reports concern request compatibility or local thread metadata/rollout handling after a connection has already been established.
Versions
- Codex Relay: 1.4.5
- Codex CLI / app-server: 0.146.0
- Node.js: 24.7.0
- OS: macOS 26.5.2
- Mobile app: version not exposed in the client UI
Summary
In shared app-server mode, the mobile thread list/detail view alternates between stale and current metadata for the same thread. One observed conversation repeatedly switched between “1 hour ago” and “7 days ago”, while opening it consistently showed messages from 1 hour ago. Its displayed message count changed at the same time.
Steps to reproduce
- Run Codex Relay 1.4.5 with
--shared-app-server.
- Resume and update an older persisted thread through the shared app-server.
- Open the Relay mobile client.
- Refresh or move between the thread list and thread detail several times.
Expected behavior
For a stable thread ID, updatedAt / lastActivityAt remain monotonic, stale summary data never overwrites newer activity, and the displayed message count does not regress.
Actual behavior
The relative activity time alternates between an old and a current value, and the message count can alternate with it. Conversation content itself remains current.
The behavior is consistent with current app-server/detail metadata and older persisted summary/rollout metadata being merged in different orders.
Logs or screenshots
No secrets or private paths are included. The visible symptom is an alternating relative timestamp (“1 hour ago” / “7 days ago”) for the same thread ID.
Possible fix
Centralize metadata merging and use the maximum valid activity timestamp. Define one authoritative message-count source, then cover list refresh, detail loading, and live updates for a resumed persisted thread in a regression test.
Language
Network checklist
Not applicable: the phone can reach Relay through the configured tunnel and load thread content. These reports concern request compatibility or local thread metadata/rollout handling after a connection has already been established.
Versions
Summary
In shared app-server mode, the mobile thread list/detail view alternates between stale and current metadata for the same thread. One observed conversation repeatedly switched between “1 hour ago” and “7 days ago”, while opening it consistently showed messages from 1 hour ago. Its displayed message count changed at the same time.
Steps to reproduce
--shared-app-server.Expected behavior
For a stable thread ID,
updatedAt/lastActivityAtremain monotonic, stale summary data never overwrites newer activity, and the displayed message count does not regress.Actual behavior
The relative activity time alternates between an old and a current value, and the message count can alternate with it. Conversation content itself remains current.
The behavior is consistent with current app-server/detail metadata and older persisted summary/rollout metadata being merged in different orders.
Logs or screenshots
No secrets or private paths are included. The visible symptom is an alternating relative timestamp (“1 hour ago” / “7 days ago”) for the same thread ID.
Possible fix
Centralize metadata merging and use the maximum valid activity timestamp. Define one authoritative message-count source, then cover list refresh, detail loading, and live updates for a resumed persisted thread in a regression test.