Desktop-created cloud sessions never receive their kickoff prompt: `session.remote.notifySteerableChanged` unsupported by the native session bridge

[harshnag]

Summary

Every cloud session created from the desktop app is dead on arrival. The remote session is created successfully in the cloud, but the app can never mark it steerable, so the kickoff prompt is never delivered. The session then sits blank and idle forever, with no error surfaced anywhere the user can see it.

The cause is an RPC method the bridge doesn't implement — not a timeout that could be tuned away:

Request session.remote.notifySteerableChanged failed with message:
Direct native session bridge does not support session method 'session.remote.notifySteerableChanged'

Environment

Field	Value
App version	1.1.8 (0945da4) and 1.1.9 (07245f4) — both affected
OS	macOS 26.6.1 (25G76), arm64
Bundled CLI	1.0.79-9
Bundled gh / git	2.96.0 / 2.53.0-4
Repo	personal, public (harshnag/multifoot)

Repro

1. Create a cloud session with a kickoff prompt — either from the UI, or via the create_session tool with execution_location: 'cloud' and a kickoff.prompt.
2. The session appears in the sidebar.
3. Nothing ever happens in it. No output, no error, no spinner resolution.
4. Reopening or restarting the app does not help; the same failure repeats on every resume.

Evidence

The app's own log names the failure and predicts its consequence:

2026-08-14T12:37:32.606550Z  WARN github_app::session::core:
  failed to mark resumed remote session steerable; sends may block
  task_id=c4766aae-9a49-48f7-b348-03d4a86c22d1
  error=RPC error -32603: Request session.remote.notifySteerableChanged failed with message:
        Direct native session bridge does not support session method 'session.remote.notifySteerableChanged'

Full sequence for one session (~/.copilot/logs/):

12:06:46  github_app::handlers::workspace: cloud kickoff: creating session workspace_id=b96049e7-…
12:06:46  github_app::session::manager::lifecycle: creating new session execution_location=Cloud
12:06:59  [CLI] Created remote session in the cloud: c4766aae-9a49-48f7-b348-03d4a86c22d1
12:06:59  github_app::session::core: CLI session created create_session_rpc_ms=12065
12:07:00  github_app::handlers::workspace: cloud kickoff: session created workspace_id=b96049e7-…
12:09:00  ERROR github_app::handlers::session: failed to send message
          error=operation timed out: cloud session was not steerable within 120s
12:09:01  ERROR frontend: [WebSocket] Server error: Failed to send message:
          operation timed out: cloud session was not steerable within 120s

So the remote session exists — it just never gets told what to do.

On the CLI side, the same session logs the corresponding failure on every resume:

12:29:28  [WARNING] Failed to setup remote exporter for session c4766aae-…:
          Error: Direct native session bridge does not support session method 'session.remote.notifySteerableChanged'
12:33:26  [WARNING] Failed to setup remote exporter for session c4766aae-… (same)
12:37:02  [WARNING] Failed to setup remote exporter for session c4766aae-… (same)

Not a one-off

The oldest occurrence in my logs is 2026-08-13T19:15:54 against a different session (e157aa75-2a9c-476e-ae2d-226dcd87fb57) on 1.1.8. The most recent is 2026-08-14T12:37:32 on 1.1.9, after the update installed at 12:29. It reproduces on demand, across two app versions, for every cloud session I create.

A separate, unrelated failure that cleared

Worth separating so it isn't mistaken for the cause. During the same window the Mission Control events endpoint was returning 503:

12:19:56  [WARNING] failed to list Mission Control task events
  {"task_id":"c4766aae-…",
   "url":"https://api.enterprise.githubcopilot.com/agents/tasks/c4766aae-…/events",
   "status":503,"body_preview":"no healthy upstream"}

That endpoint responds normally now (400 missing-auth), githubstatus.com shows Copilot operational, and the steerability failure continues regardless. The 503 was transient; the bridge gap is not.

The cloud agent backend itself is fine

Tasks started outside the desktop app run normally against the same repo and account — 46 copilot/task-* branches with commits landing today at 11:36, 12:13 and 12:22. This is specifically the desktop app's kickoff/steering path.

Impact

Cloud sessions are the app's recommended way to hand work off to run unattended, and they're the only kind steerable later from GitHub Mobile. Right now, creating one from the desktop produces a session that looks created and does nothing — which is worse than a visible failure, because a user reasonably assumes it's working and comes back hours later to an empty session.

For my own project this is load-bearing: our AGENTS.md instructs each session to create its successor with execution_location: 'cloud' precisely so successors never share a local working tree. That instruction is currently unexecutable from the desktop app.

Suggested fixes

1. Implement session.remote.notifySteerableChanged on the direct native session bridge (or route remote-exporter setup via a bridge that supports it).
2. Failing that, don't gate the kickoff send on a steerability signal that can never arrive — if the notify RPC is unsupported, fall back to polling readiness or send optimistically rather than blocking for 120s.
3. Surface the failure in the UI. failed to mark resumed remote session steerable; sends may block and not steerable within 120s both exist at WARN/ERROR in the log, and neither reaches the user. A session that will never respond should say so.

Related, but not duplicates

• **[Gap / feature request] Desktop app can't list or steer GitHub-hosted cloud... #2383 — desktop can't list or resume cloud sessions started on github.com/mobile. That's about externally created sessions; these are created by the desktop and still fail.
• Remote stays in Connecting #2110 — session.remote.enable failing on remote-control toggle. Different call, different path.
• "Failed to start cloud session" on first try :/ #1917 — "Failed to start cloud session". Mine does start (Created remote session in the cloud); it just never receives the prompt.
• Session-creation worktree timeout (~60s) too short for large Windows repos - kickoff silently dropped, sessions become permanently dormant #111 (closed) — closest in shape: "kickoff silently dropped, sessions become permanently dormant" when a session-creation timeout was too short, for worktrees. Same symptom class, but that one was fixed by lengthening a timeout, which cannot help here — the method is absent, so no wait is long enough.

Happy to supply full logs if useful.