Summary
/remote on appears to stop working partway through a long-running Copilot CLI session. Toggling /remote off then /remote on did not restore the connection — the GitHub mobile app continued to show the session as "off / not remote-enabled". The only working remediation was to abandon the session entirely and start a fresh one.
Environment
- Copilot CLI version: 1.0.49-1
- Platform: macOS (Darwin)
- Model in session:
claude-opus-4.7-1m-internal
- Session length when issue surfaced: very long (multi-day session with overnight scheduled prompts via
/schedule)
Steps to reproduce
- Start a Copilot CLI session and enable
/remote on.
- Confirm the session shows as remote-enabled in the GitHub mobile app.
- Let the session run for an extended period (in our case: multi-day, with
manage_schedule background heartbeats firing every 30 min overnight).
- Return to the GitHub mobile app and try to interact remotely.
Expected
The session continues to appear as remote-enabled and accepts remote input from the GitHub mobile/web app.
Actual
- The GitHub mobile app shows the session as "off" / not remote-controllable, even though
/remote inside the CLI reports it as on.
- Toggling
/remote off then /remote on from inside the CLI does not restore the link.
- No error message is shown on either side.
- Only workaround: end the session and start a new one, then
/remote on from the fresh session.
Impact
The whole point of /remote is to check in on long-running, possibly overnight work from a phone. Losing the link silently during exactly the kind of long sessions it's designed for defeats the feature. Starting over also loses in-memory session state (scheduled prompts via manage_schedule are session-scoped and end with the session — this compounds the cost of having to start over).
Suggested investigation
- Is there a server-side heartbeat / WS keepalive that's timing out for long-idle sessions?
- Does
/remote on re-register with the GitHub app side, or does it only flip a local flag?
- Is there a way to surface the broken link in the CLI so users don't think it's still working?
Happy to share more context (anonymized session ID, approximate timing) if useful.
Summary
/remote onappears to stop working partway through a long-running Copilot CLI session. Toggling/remote offthen/remote ondid not restore the connection — the GitHub mobile app continued to show the session as "off / not remote-enabled". The only working remediation was to abandon the session entirely and start a fresh one.Environment
claude-opus-4.7-1m-internal/schedule)Steps to reproduce
/remote on.manage_schedulebackground heartbeats firing every 30 min overnight).Expected
The session continues to appear as remote-enabled and accepts remote input from the GitHub mobile/web app.
Actual
/remoteinside the CLI reports it as on./remote offthen/remote onfrom inside the CLI does not restore the link./remote onfrom the fresh session.Impact
The whole point of
/remoteis to check in on long-running, possibly overnight work from a phone. Losing the link silently during exactly the kind of long sessions it's designed for defeats the feature. Starting over also loses in-memory session state (scheduled prompts viamanage_scheduleare session-scoped and end with the session — this compounds the cost of having to start over).Suggested investigation
/remote onre-register with the GitHub app side, or does it only flip a local flag?Happy to share more context (anonymized session ID, approximate timing) if useful.