Copilot

Sentinel can also run a thread on GitHub Copilot, through the Copilot SDK.

The model runtime changes, but the thread model and app shell stay where they are.

SetupCopy Anchor Link

Clearing the binary path goes back to the bundled runtime.

Sign-inCopy Anchor Link

• Sign in with GitHub runs copilot login in a terminal inside the Copilot card, into the instance's home.
• Use a GitHub token stores a fine-grained token with the Copilot Requests permission, encrypted on the instance as COPILOT_GITHUB_TOKEN.

What Sentinel keeps for a Copilot threadCopy Anchor Link

A Copilot-backed thread can carry:

• Copilot session ID
• working directory
• model
• reasoning effort
• the instance it runs on

That is enough for Sentinel to reopen the thread and keep the runtime connection lined up with the rest of the thread state.

The split is close to Claude Code.

Sentinel keeps the durable thread record. GitHub Copilot keeps the active local session.

Runtime status and authCopy Anchor Link

Copilot has its own runtime-status surface inside Sentinel.

That status layer is doing a little more than simple model discovery.

The app checks whether the runtime is present, whether auth is ready, and whether the runtime can return the current model list in time.

That matters because a local runtime can be installed but still not be ready to run a thread if auth is missing.

Model handlingCopy Anchor Link

Sentinel asks the local Copilot setup for runtime status and available models.

If the local runtime responds normally, the app uses those runtime models directly.

If the runtime is present and authenticated but model discovery times out, Sentinel can still surface a small fallback model list so the thread UI does not stall out.

That fallback matters for the same reason it matters on Codex and Claude: local runtime checks can be a little uneven.

So here too, the app is trying to keep the thread stable even when runtime discovery is slower than the main UI expects.

Run shapeCopy Anchor Link

GitHub Copilot sits in roughly the same product position as Claude and Codex:

The main difference is the runtime state surface. The outer product shape stays the same.

The session record is still smaller than the Codex one, but the pattern is familiar:

1. Resolve the saved Copilot-linked thread state.
2. Send the current turn into the Copilot session.
3. Stream output and status back through the thread.
4. Persist the updated state in Sentinel around the runtime.

Permission and plan modeCopy Anchor Link

Copilot threads use Sentinel's Default and Full permission modes. In Default, shell, read, write, and web requests follow your approval settings, and requests for MCP servers, custom tools, hooks, and extensions always ask.

Copilot has no plan mode Sentinel can drive, so plan mode uses Sentinel's plan prompt.

Code shapeCopy Anchor Link

The Copilot state surface is defined explicitly in the runtime types:

export const copilotThreadStateSchema = z.object({
  ...threadStateSessionMeta,
  cwd: z.string().nullish(),
  modelId: z.string().nullish(),
  reasoningEffort: z.enum(REASONING_EFFORTS).nullish(),
  sessionId: z.string(),
});

What stays in SentinelCopy Anchor Link

Even when GitHub Copilot is running the thread, Sentinel still owns:

• the thread list
• the workspace state
• the repo panels
• the shell
• settings

So the runtime changes, but the rest of the product stays steady.

Code referencesCopy Anchor Link

• state/copilot.ts
• copilot-sdk.ts
• drivers/copilot.ts