Operate the system
Use the offline outbox and reconnect safely
Mobile networks fail in the middle of work. FireCursor can queue supported messages in an offline outbox and reconnect active sessions, while keeping delivery state visible.
Quick answer
The shortest useful version.
When offline, queue only non-sensitive messages that remain valid later. After reconnection, confirm the project, session, and agent state before allowing the outbox to continue the task.
Step by step
Do this with confidence.
- 01
Notice the connection state
Treat offline and reconnecting indicators as workflow state. Do not assume a tap reached the agent.
- 02
Queue stable instructions
A safe queued message should still make sense if delivered after a delay. Avoid time-sensitive approvals or destructive commands.
- 03
Reconfirm on reconnect
Verify project identity, session status, pending questions, and whether another device or operator advanced the work.
- 04
Resolve duplicates
Check delivery state before resending. If the task changed while offline, remove or supersede stale messages explicitly.
What not to queue
- Allow-always or reject-always decisions
- Production deploy or publish instructions
- Messages containing pairing tokens or credentials
- A response to a question whose context may change
- Duplicate prompts sent only because the UI felt slow
Reconnection is a state reconciliation problem
A restored socket does not automatically mean the conversation state is safe to continue. The client needs to reconcile delivered messages, active run status, and current project identity.
FireCursor’s outbox and session history make that uncertainty visible so the operator can decide rather than guess.