Add Github Copilot Provider

[zortos293]

What Changed

• Added GitHub Copilot as a first-class provider using the official Copilot SDK.
• Wired Copilot through the server runtime, including provider detection, auth/status reporting, model discovery, session startup/resume, turn sending, request handling, and event streaming.
• Added Copilot-backed git text generation for commit messages, PR content, branch names, and thread titles.
• Added Copilot to shared contracts/settings so it behaves like the existing providers for model selection, reasoning options, defaults, and persisted settings.
• Updated the web app so Copilot appears in the provider/model dropdowns, settings panels, custom model management, composer state, and git writing model selection.

Why

T3 Code already supports multiple agent providers, but it did not have GitHub Copilot support. This change adds Copilot end to end in the same shape as the other providers instead of treating it as a one-off integration.

That keeps the UX and server behavior consistent: users can configure Copilot in settings, select Copilot models from the same pickers, use it for git text generation, and rely on the same persistence and runtime flows that already exist for other providers. Using the official SDK also keeps the integration aligned with GitHub’s supported protocol and model discovery/auth flows.

UI Changes

• Added Copilot to the provider picker.
• Added a Copilot settings section with binary path, server URL, and custom model configuration.
• Added Copilot to the git writing model picker and traits handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

High Risk
Adds a new first-class provider with complex session/event handling and introduces the @github/copilot-sdk runtime dependency, so failures/auth/model discovery issues could impact provider startup and chat/runtime flows.

Overview
Adds GitHub Copilot as a first-class provider end-to-end. The server now includes a new CopilotDriver registered in BUILT_IN_DRIVERS, a Copilot SDK runtime wrapper (copilotRuntime.ts) for auth/status/model probing, and a full CopilotAdapter that starts/resumes sessions, translates Copilot SDK events into provider runtime events (turn lifecycle, streaming deltas, tool execution, permissions/user-input), and hardens error/cleanup behavior.

Adds Copilot-backed git text generation (CopilotTextGeneration.ts) for commit messages/PR content/branch names/thread titles with pooled SDK clients and idle shutdown. Updates shared contracts/settings to include CopilotSettings, provider defaults/aliases/display names, and extends runtime raw event sources; the web app surfaces Copilot in provider pickers/settings/icons and removes the “coming soon” placeholder when a real Copilot instance exists. Includes extensive new tests covering adapter behavior, provider probe errors, and text-generation client reuse.

^{Reviewed by Cursor Bugbot for commit 2a55f8a. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add GitHub Copilot as a built-in provider for chat and text generation

• Adds a full CopilotDriver and CopilotAdapter that integrate with @github/copilot-sdk to support chat sessions, permission handling, and runtime event translation.
• Adds makeCopilotTextGeneration to generate commit messages, PR content, branch names, and thread titles via Copilot models using structured JSON outputs and a shared client pool.
• Adds checkCopilotProviderStatus to periodically probe the Copilot SDK for auth state, available models, and version info.
• Updates the settings UI, model picker, and provider icon mapping to treat Copilot as a first-class provider, removing the "Coming soon" placeholder.
• Risk: introduces a new runtime dependency @github/copilot-sdk@^0.2.2 and spawns external CLI processes; probe failures are surfaced as provider errors rather than silently ignored.

^{Macroscope summarized d464878.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 6417f1bb-b9f1-4115-890c-8459048c5942

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR adds a new GitHub Copilot provider integration with ~4500 lines of new code, external SDK dependencies, and complex session management. New feature additions with this scope require human review. Additionally, an unresolved high-severity comment identifies a potential race condition in session teardown that could cause lost events.

^{You can customize Macroscope's approvability policy. Learn more.}

[zortos293]

This needs to be tested if the desktop app is working fine with Copilot

[brrock]

Because julius plumbed in ACP can't we just use ACP, I guess the copilot sdk has copilot specific stuff

[cursor]

Copilot enabled by default causes unwanted CLI spawns

Medium Severity

CopilotSettings defaults enabled to true, meaning every existing user who upgrades will have Copilot auto-enabled. Combined with the 1-hour COPILOT_REFRESH_INTERVAL, this will repeatedly spawn the bundled Copilot CLI binary, attempt auth checks, and fail for the majority of users who have no GitHub Copilot subscription or auth configured. Unlike Codex/Claude/OpenCode which are the app's core providers, Copilot is a newly added optional integration — defaulting to false (like Cursor does) would avoid unnecessary process spawns and error noise on every refresh cycle.

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotProvider.ts#L18-L19

^{Reviewed by Cursor Bugbot for commit c9b851217439d17fbbe96d68b3f89077440f3446. Configure here.}

[rgembalik]

I am not a maintainer, but I did couple of local tests. There were few cases where session stopped without showing final results message. I don't know if this is upstream bug, or something related to the PR (currently I have only copilot license so it's hard to test against other providers). After asking, I got a response that the results were there, but probably didn't show on my end.

[zortos293]

i'l look into this

[brrock]

conflicts btw

[zortos293]

conflicts btw

imma look at it tmr 👍

[macroscopeapp]

🟢 LowLayers/CopilotProvider.ts:61

The checkedAt timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when checkCopilotProviderStatus was first invoked. Since makeManagedServerProvider re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.

 if (!input.settings.enabled) {
return Effect.succeed(makePendingCopilotProvider(input.settings));
}
- const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const fallback = (cause: unknown, version: string | null = null) => {
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const failure = formatCopilotProbeError({
cause,
settings: input.settings,
@@ -92,6 +92,7 @@
});
};
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
return Effect.acquireUseRelease(

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotProvider.ts around lines 61-147:
The `checkedAt` timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when `checkCopilotProviderStatus` was first invoked. Since `makeManagedServerProvider` re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.
Evidence trail:
apps/server/src/provider/Layers/CopilotProvider.ts lines 61-70 (checkedAt captured eagerly outside Effect), lines 95-149 (Effect.acquireUseRelease returned, closing over checkedAt). apps/server/src/provider/Drivers/CopilotDriver.ts lines 92-95 (checkCopilotProviderStatus called once, Effect passed as checkProvider). apps/server/src/provider/makeManagedServerProvider.ts lines 127-130 (input.checkProvider re-executed in applySnapshotBase), lines 163-168 (forever loop re-running refreshSnapshot on each interval).

[macroscopeapp]

🟢 LowLayers/CopilotAdapter.ts:2264

In respondToRequest, after resolving binding.deferred, the requestId is not removed from pendingPermissionBindings. If called twice with the same requestId, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.

- yield* Deferred.succeed(binding.deferred, result);+ yield* Deferred.succeed(binding.deferred, result);+ context.pendingPermissionBindings.delete(requestId);

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotAdapter.ts around line 2264:
In `respondToRequest`, after resolving `binding.deferred`, the `requestId` is not removed from `pendingPermissionBindings`. If called twice with the same `requestId`, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.
Evidence trail:
apps/server/src/provider/Layers/CopilotAdapter.ts lines 2248-2265 (respondToRequest function: no delete after Deferred.succeed at line 2264). Compare with lines 574-577 (settlePendingPermissionHandlers: calls .clear() after settling). Effect-TS Deferred.succeed returns Effect<boolean> — false if already done, no error thrown (see Effect-TS source/docs).

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[cursor]

Session teardown doesn't await pending event chain

High Severity

stopSessionInternal disconnects the SDK session and stops the client without first awaiting context.eventChain. Events still being processed asynchronously in the chain (including turn.completed and item.completed events) can race against or fail after the SDK resources are torn down. This likely explains the reported bug where sessions stop without surfacing final results. In contrast, startSession correctly awaits the chain at line 2180 with yield* Effect.promise(() => context.eventChain).

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotAdapter.ts#L2176-L2180

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[juliusmarminge]

A newer Copilot provider implementation, #3076, is active against the current provider architecture. Keeping this older provider branch would duplicate that effort.

This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.

[zortos293]

What Changed

• Added GitHub Copilot as a first-class provider using the official Copilot SDK.
• Wired Copilot through the server runtime, including provider detection, auth/status reporting, model discovery, session startup/resume, turn sending, request handling, and event streaming.
• Added Copilot-backed git text generation for commit messages, PR content, branch names, and thread titles.
• Added Copilot to shared contracts/settings so it behaves like the existing providers for model selection, reasoning options, defaults, and persisted settings.
• Updated the web app so Copilot appears in the provider/model dropdowns, settings panels, custom model management, composer state, and git writing model selection.

Why

T3 Code already supports multiple agent providers, but it did not have GitHub Copilot support. This change adds Copilot end to end in the same shape as the other providers instead of treating it as a one-off integration.

That keeps the UX and server behavior consistent: users can configure Copilot in settings, select Copilot models from the same pickers, use it for git text generation, and rely on the same persistence and runtime flows that already exist for other providers. Using the official SDK also keeps the integration aligned with GitHub’s supported protocol and model discovery/auth flows.

UI Changes

• Added Copilot to the provider picker.
• Added a Copilot settings section with binary path, server URL, and custom model configuration.
• Added Copilot to the git writing model picker and traits handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

High Risk
Adds a new first-class provider with complex session/event handling and introduces the @github/copilot-sdk runtime dependency, so failures/auth/model discovery issues could impact provider startup and chat/runtime flows.

Overview
Adds GitHub Copilot as a first-class provider end-to-end. The server now includes a new CopilotDriver registered in BUILT_IN_DRIVERS, a Copilot SDK runtime wrapper (copilotRuntime.ts) for auth/status/model probing, and a full CopilotAdapter that starts/resumes sessions, translates Copilot SDK events into provider runtime events (turn lifecycle, streaming deltas, tool execution, permissions/user-input), and hardens error/cleanup behavior.

Adds Copilot-backed git text generation (CopilotTextGeneration.ts) for commit messages/PR content/branch names/thread titles with pooled SDK clients and idle shutdown. Updates shared contracts/settings to include CopilotSettings, provider defaults/aliases/display names, and extends runtime raw event sources; the web app surfaces Copilot in provider pickers/settings/icons and removes the “coming soon” placeholder when a real Copilot instance exists. Includes extensive new tests covering adapter behavior, provider probe errors, and text-generation client reuse.

^{Reviewed by Cursor Bugbot for commit 2a55f8a. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add GitHub Copilot as a built-in provider for chat and text generation

• Adds a full CopilotDriver and CopilotAdapter that integrate with @github/copilot-sdk to support chat sessions, permission handling, and runtime event translation.
• Adds makeCopilotTextGeneration to generate commit messages, PR content, branch names, and thread titles via Copilot models using structured JSON outputs and a shared client pool.
• Adds checkCopilotProviderStatus to periodically probe the Copilot SDK for auth state, available models, and version info.
• Updates the settings UI, model picker, and provider icon mapping to treat Copilot as a first-class provider, removing the "Coming soon" placeholder.
• Risk: introduces a new runtime dependency @github/copilot-sdk@^0.2.2 and spawns external CLI processes; probe failures are surfaced as provider errors rather than silently ignored.

^{Macroscope summarized d464878.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 6417f1bb-b9f1-4115-890c-8459048c5942

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR adds a new GitHub Copilot provider integration with ~4500 lines of new code, external SDK dependencies, and complex session management. New feature additions with this scope require human review. Additionally, an unresolved high-severity comment identifies a potential race condition in session teardown that could cause lost events.

^{You can customize Macroscope's approvability policy. Learn more.}

[zortos293]

This needs to be tested if the desktop app is working fine with Copilot

[brrock]

Because julius plumbed in ACP can't we just use ACP, I guess the copilot sdk has copilot specific stuff

[cursor]

Copilot enabled by default causes unwanted CLI spawns

Medium Severity

CopilotSettings defaults enabled to true, meaning every existing user who upgrades will have Copilot auto-enabled. Combined with the 1-hour COPILOT_REFRESH_INTERVAL, this will repeatedly spawn the bundled Copilot CLI binary, attempt auth checks, and fail for the majority of users who have no GitHub Copilot subscription or auth configured. Unlike Codex/Claude/OpenCode which are the app's core providers, Copilot is a newly added optional integration — defaulting to false (like Cursor does) would avoid unnecessary process spawns and error noise on every refresh cycle.

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotProvider.ts#L18-L19

^{Reviewed by Cursor Bugbot for commit c9b851217439d17fbbe96d68b3f89077440f3446. Configure here.}

[rgembalik]

I am not a maintainer, but I did couple of local tests. There were few cases where session stopped without showing final results message. I don't know if this is upstream bug, or something related to the PR (currently I have only copilot license so it's hard to test against other providers). After asking, I got a response that the results were there, but probably didn't show on my end.

[zortos293]

i'l look into this

[brrock]

conflicts btw

[zortos293]

conflicts btw

imma look at it tmr 👍

[macroscopeapp]

🟢 LowLayers/CopilotProvider.ts:61

The checkedAt timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when checkCopilotProviderStatus was first invoked. Since makeManagedServerProvider re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.

 if (!input.settings.enabled) {
return Effect.succeed(makePendingCopilotProvider(input.settings));
}
- const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const fallback = (cause: unknown, version: string | null = null) => {
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const failure = formatCopilotProbeError({
cause,
settings: input.settings,
@@ -92,6 +92,7 @@
});
};
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
return Effect.acquireUseRelease(

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotProvider.ts around lines 61-147:
The `checkedAt` timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when `checkCopilotProviderStatus` was first invoked. Since `makeManagedServerProvider` re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.
Evidence trail:
apps/server/src/provider/Layers/CopilotProvider.ts lines 61-70 (checkedAt captured eagerly outside Effect), lines 95-149 (Effect.acquireUseRelease returned, closing over checkedAt). apps/server/src/provider/Drivers/CopilotDriver.ts lines 92-95 (checkCopilotProviderStatus called once, Effect passed as checkProvider). apps/server/src/provider/makeManagedServerProvider.ts lines 127-130 (input.checkProvider re-executed in applySnapshotBase), lines 163-168 (forever loop re-running refreshSnapshot on each interval).

[macroscopeapp]

🟢 LowLayers/CopilotAdapter.ts:2264

In respondToRequest, after resolving binding.deferred, the requestId is not removed from pendingPermissionBindings. If called twice with the same requestId, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.

- yield* Deferred.succeed(binding.deferred, result);+ yield* Deferred.succeed(binding.deferred, result);+ context.pendingPermissionBindings.delete(requestId);

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotAdapter.ts around line 2264:
In `respondToRequest`, after resolving `binding.deferred`, the `requestId` is not removed from `pendingPermissionBindings`. If called twice with the same `requestId`, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.
Evidence trail:
apps/server/src/provider/Layers/CopilotAdapter.ts lines 2248-2265 (respondToRequest function: no delete after Deferred.succeed at line 2264). Compare with lines 574-577 (settlePendingPermissionHandlers: calls .clear() after settling). Effect-TS Deferred.succeed returns Effect<boolean> — false if already done, no error thrown (see Effect-TS source/docs).

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[cursor]

Session teardown doesn't await pending event chain

High Severity

stopSessionInternal disconnects the SDK session and stops the client without first awaiting context.eventChain. Events still being processed asynchronously in the chain (including turn.completed and item.completed events) can race against or fail after the SDK resources are torn down. This likely explains the reported bug where sessions stop without surfacing final results. In contrast, startSession correctly awaits the chain at line 2180 with yield* Effect.promise(() => context.eventChain).

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotAdapter.ts#L2176-L2180

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[juliusmarminge]

A newer Copilot provider implementation, #3076, is active against the current provider architecture. Keeping this older provider branch would duplicate that effort.

This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.

[zortos293]

What Changed

• Added GitHub Copilot as a first-class provider using the official Copilot SDK.
• Wired Copilot through the server runtime, including provider detection, auth/status reporting, model discovery, session startup/resume, turn sending, request handling, and event streaming.
• Added Copilot-backed git text generation for commit messages, PR content, branch names, and thread titles.
• Added Copilot to shared contracts/settings so it behaves like the existing providers for model selection, reasoning options, defaults, and persisted settings.
• Updated the web app so Copilot appears in the provider/model dropdowns, settings panels, custom model management, composer state, and git writing model selection.

Why

T3 Code already supports multiple agent providers, but it did not have GitHub Copilot support. This change adds Copilot end to end in the same shape as the other providers instead of treating it as a one-off integration.

That keeps the UX and server behavior consistent: users can configure Copilot in settings, select Copilot models from the same pickers, use it for git text generation, and rely on the same persistence and runtime flows that already exist for other providers. Using the official SDK also keeps the integration aligned with GitHub’s supported protocol and model discovery/auth flows.

UI Changes

• Added Copilot to the provider picker.
• Added a Copilot settings section with binary path, server URL, and custom model configuration.
• Added Copilot to the git writing model picker and traits handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

High Risk
Adds a new first-class provider with complex session/event handling and introduces the @github/copilot-sdk runtime dependency, so failures/auth/model discovery issues could impact provider startup and chat/runtime flows.

Overview
Adds GitHub Copilot as a first-class provider end-to-end. The server now includes a new CopilotDriver registered in BUILT_IN_DRIVERS, a Copilot SDK runtime wrapper (copilotRuntime.ts) for auth/status/model probing, and a full CopilotAdapter that starts/resumes sessions, translates Copilot SDK events into provider runtime events (turn lifecycle, streaming deltas, tool execution, permissions/user-input), and hardens error/cleanup behavior.

Adds Copilot-backed git text generation (CopilotTextGeneration.ts) for commit messages/PR content/branch names/thread titles with pooled SDK clients and idle shutdown. Updates shared contracts/settings to include CopilotSettings, provider defaults/aliases/display names, and extends runtime raw event sources; the web app surfaces Copilot in provider pickers/settings/icons and removes the “coming soon” placeholder when a real Copilot instance exists. Includes extensive new tests covering adapter behavior, provider probe errors, and text-generation client reuse.

^{Reviewed by Cursor Bugbot for commit 2a55f8a. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add GitHub Copilot as a built-in provider for chat and text generation

• Adds a full CopilotDriver and CopilotAdapter that integrate with @github/copilot-sdk to support chat sessions, permission handling, and runtime event translation.
• Adds makeCopilotTextGeneration to generate commit messages, PR content, branch names, and thread titles via Copilot models using structured JSON outputs and a shared client pool.
• Adds checkCopilotProviderStatus to periodically probe the Copilot SDK for auth state, available models, and version info.
• Updates the settings UI, model picker, and provider icon mapping to treat Copilot as a first-class provider, removing the "Coming soon" placeholder.
• Risk: introduces a new runtime dependency @github/copilot-sdk@^0.2.2 and spawns external CLI processes; probe failures are surfaced as provider errors rather than silently ignored.

^{Macroscope summarized d464878.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 6417f1bb-b9f1-4115-890c-8459048c5942

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR adds a new GitHub Copilot provider integration with ~4500 lines of new code, external SDK dependencies, and complex session management. New feature additions with this scope require human review. Additionally, an unresolved high-severity comment identifies a potential race condition in session teardown that could cause lost events.

^{You can customize Macroscope's approvability policy. Learn more.}

[zortos293]

This needs to be tested if the desktop app is working fine with Copilot

[brrock]

Because julius plumbed in ACP can't we just use ACP, I guess the copilot sdk has copilot specific stuff

[cursor]

Copilot enabled by default causes unwanted CLI spawns

Medium Severity

CopilotSettings defaults enabled to true, meaning every existing user who upgrades will have Copilot auto-enabled. Combined with the 1-hour COPILOT_REFRESH_INTERVAL, this will repeatedly spawn the bundled Copilot CLI binary, attempt auth checks, and fail for the majority of users who have no GitHub Copilot subscription or auth configured. Unlike Codex/Claude/OpenCode which are the app's core providers, Copilot is a newly added optional integration — defaulting to false (like Cursor does) would avoid unnecessary process spawns and error noise on every refresh cycle.

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotProvider.ts#L18-L19

^{Reviewed by Cursor Bugbot for commit c9b851217439d17fbbe96d68b3f89077440f3446. Configure here.}

[rgembalik]

I am not a maintainer, but I did couple of local tests. There were few cases where session stopped without showing final results message. I don't know if this is upstream bug, or something related to the PR (currently I have only copilot license so it's hard to test against other providers). After asking, I got a response that the results were there, but probably didn't show on my end.

[zortos293]

i'l look into this

[brrock]

conflicts btw

[zortos293]

conflicts btw

imma look at it tmr 👍

[macroscopeapp]

🟢 LowLayers/CopilotProvider.ts:61

The checkedAt timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when checkCopilotProviderStatus was first invoked. Since makeManagedServerProvider re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.

 if (!input.settings.enabled) {
return Effect.succeed(makePendingCopilotProvider(input.settings));
}
- const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const fallback = (cause: unknown, version: string | null = null) => {
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const failure = formatCopilotProbeError({
cause,
settings: input.settings,
@@ -92,6 +92,7 @@
});
};
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
return Effect.acquireUseRelease(

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotProvider.ts around lines 61-147:
The `checkedAt` timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when `checkCopilotProviderStatus` was first invoked. Since `makeManagedServerProvider` re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.
Evidence trail:
apps/server/src/provider/Layers/CopilotProvider.ts lines 61-70 (checkedAt captured eagerly outside Effect), lines 95-149 (Effect.acquireUseRelease returned, closing over checkedAt). apps/server/src/provider/Drivers/CopilotDriver.ts lines 92-95 (checkCopilotProviderStatus called once, Effect passed as checkProvider). apps/server/src/provider/makeManagedServerProvider.ts lines 127-130 (input.checkProvider re-executed in applySnapshotBase), lines 163-168 (forever loop re-running refreshSnapshot on each interval).

[macroscopeapp]

🟢 LowLayers/CopilotAdapter.ts:2264

In respondToRequest, after resolving binding.deferred, the requestId is not removed from pendingPermissionBindings. If called twice with the same requestId, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.

- yield* Deferred.succeed(binding.deferred, result);+ yield* Deferred.succeed(binding.deferred, result);+ context.pendingPermissionBindings.delete(requestId);

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotAdapter.ts around line 2264:
In `respondToRequest`, after resolving `binding.deferred`, the `requestId` is not removed from `pendingPermissionBindings`. If called twice with the same `requestId`, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.
Evidence trail:
apps/server/src/provider/Layers/CopilotAdapter.ts lines 2248-2265 (respondToRequest function: no delete after Deferred.succeed at line 2264). Compare with lines 574-577 (settlePendingPermissionHandlers: calls .clear() after settling). Effect-TS Deferred.succeed returns Effect<boolean> — false if already done, no error thrown (see Effect-TS source/docs).

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[cursor]

Session teardown doesn't await pending event chain

High Severity

stopSessionInternal disconnects the SDK session and stops the client without first awaiting context.eventChain. Events still being processed asynchronously in the chain (including turn.completed and item.completed events) can race against or fail after the SDK resources are torn down. This likely explains the reported bug where sessions stop without surfacing final results. In contrast, startSession correctly awaits the chain at line 2180 with yield* Effect.promise(() => context.eventChain).

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotAdapter.ts#L2176-L2180

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[juliusmarminge]

A newer Copilot provider implementation, #3076, is active against the current provider architecture. Keeping this older provider branch would duplicate that effort.

This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.

[zortos293]

What Changed

• Added GitHub Copilot as a first-class provider using the official Copilot SDK.
• Wired Copilot through the server runtime, including provider detection, auth/status reporting, model discovery, session startup/resume, turn sending, request handling, and event streaming.
• Added Copilot-backed git text generation for commit messages, PR content, branch names, and thread titles.
• Added Copilot to shared contracts/settings so it behaves like the existing providers for model selection, reasoning options, defaults, and persisted settings.
• Updated the web app so Copilot appears in the provider/model dropdowns, settings panels, custom model management, composer state, and git writing model selection.

Why

T3 Code already supports multiple agent providers, but it did not have GitHub Copilot support. This change adds Copilot end to end in the same shape as the other providers instead of treating it as a one-off integration.

That keeps the UX and server behavior consistent: users can configure Copilot in settings, select Copilot models from the same pickers, use it for git text generation, and rely on the same persistence and runtime flows that already exist for other providers. Using the official SDK also keeps the integration aligned with GitHub’s supported protocol and model discovery/auth flows.

UI Changes

• Added Copilot to the provider picker.
• Added a Copilot settings section with binary path, server URL, and custom model configuration.
• Added Copilot to the git writing model picker and traits handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

High Risk
Adds a new first-class provider with complex session/event handling and introduces the @github/copilot-sdk runtime dependency, so failures/auth/model discovery issues could impact provider startup and chat/runtime flows.

Overview
Adds GitHub Copilot as a first-class provider end-to-end. The server now includes a new CopilotDriver registered in BUILT_IN_DRIVERS, a Copilot SDK runtime wrapper (copilotRuntime.ts) for auth/status/model probing, and a full CopilotAdapter that starts/resumes sessions, translates Copilot SDK events into provider runtime events (turn lifecycle, streaming deltas, tool execution, permissions/user-input), and hardens error/cleanup behavior.

Adds Copilot-backed git text generation (CopilotTextGeneration.ts) for commit messages/PR content/branch names/thread titles with pooled SDK clients and idle shutdown. Updates shared contracts/settings to include CopilotSettings, provider defaults/aliases/display names, and extends runtime raw event sources; the web app surfaces Copilot in provider pickers/settings/icons and removes the “coming soon” placeholder when a real Copilot instance exists. Includes extensive new tests covering adapter behavior, provider probe errors, and text-generation client reuse.

^{Reviewed by Cursor Bugbot for commit 2a55f8a. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add GitHub Copilot as a built-in provider for chat and text generation

• Adds a full CopilotDriver and CopilotAdapter that integrate with @github/copilot-sdk to support chat sessions, permission handling, and runtime event translation.
• Adds makeCopilotTextGeneration to generate commit messages, PR content, branch names, and thread titles via Copilot models using structured JSON outputs and a shared client pool.
• Adds checkCopilotProviderStatus to periodically probe the Copilot SDK for auth state, available models, and version info.
• Updates the settings UI, model picker, and provider icon mapping to treat Copilot as a first-class provider, removing the "Coming soon" placeholder.
• Risk: introduces a new runtime dependency @github/copilot-sdk@^0.2.2 and spawns external CLI processes; probe failures are surfaced as provider errors rather than silently ignored.

^{Macroscope summarized d464878.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 6417f1bb-b9f1-4115-890c-8459048c5942

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR adds a new GitHub Copilot provider integration with ~4500 lines of new code, external SDK dependencies, and complex session management. New feature additions with this scope require human review. Additionally, an unresolved high-severity comment identifies a potential race condition in session teardown that could cause lost events.

^{You can customize Macroscope's approvability policy. Learn more.}

[zortos293]

This needs to be tested if the desktop app is working fine with Copilot

[brrock]

Because julius plumbed in ACP can't we just use ACP, I guess the copilot sdk has copilot specific stuff

[cursor]

Copilot enabled by default causes unwanted CLI spawns

Medium Severity

CopilotSettings defaults enabled to true, meaning every existing user who upgrades will have Copilot auto-enabled. Combined with the 1-hour COPILOT_REFRESH_INTERVAL, this will repeatedly spawn the bundled Copilot CLI binary, attempt auth checks, and fail for the majority of users who have no GitHub Copilot subscription or auth configured. Unlike Codex/Claude/OpenCode which are the app's core providers, Copilot is a newly added optional integration — defaulting to false (like Cursor does) would avoid unnecessary process spawns and error noise on every refresh cycle.

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotProvider.ts#L18-L19

^{Reviewed by Cursor Bugbot for commit c9b851217439d17fbbe96d68b3f89077440f3446. Configure here.}

[rgembalik]

I am not a maintainer, but I did couple of local tests. There were few cases where session stopped without showing final results message. I don't know if this is upstream bug, or something related to the PR (currently I have only copilot license so it's hard to test against other providers). After asking, I got a response that the results were there, but probably didn't show on my end.

[zortos293]

i'l look into this

[brrock]

conflicts btw

[zortos293]

conflicts btw

imma look at it tmr 👍

[macroscopeapp]

🟢 LowLayers/CopilotProvider.ts:61

The checkedAt timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when checkCopilotProviderStatus was first invoked. Since makeManagedServerProvider re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.

 if (!input.settings.enabled) {
return Effect.succeed(makePendingCopilotProvider(input.settings));
}
- const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const fallback = (cause: unknown, version: string | null = null) => {
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const failure = formatCopilotProbeError({
cause,
settings: input.settings,
@@ -92,6 +92,7 @@
});
};
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
return Effect.acquireUseRelease(

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotProvider.ts around lines 61-147:
The `checkedAt` timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when `checkCopilotProviderStatus` was first invoked. Since `makeManagedServerProvider` re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.
Evidence trail:
apps/server/src/provider/Layers/CopilotProvider.ts lines 61-70 (checkedAt captured eagerly outside Effect), lines 95-149 (Effect.acquireUseRelease returned, closing over checkedAt). apps/server/src/provider/Drivers/CopilotDriver.ts lines 92-95 (checkCopilotProviderStatus called once, Effect passed as checkProvider). apps/server/src/provider/makeManagedServerProvider.ts lines 127-130 (input.checkProvider re-executed in applySnapshotBase), lines 163-168 (forever loop re-running refreshSnapshot on each interval).

[macroscopeapp]

🟢 LowLayers/CopilotAdapter.ts:2264

In respondToRequest, after resolving binding.deferred, the requestId is not removed from pendingPermissionBindings. If called twice with the same requestId, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.

- yield* Deferred.succeed(binding.deferred, result);+ yield* Deferred.succeed(binding.deferred, result);+ context.pendingPermissionBindings.delete(requestId);

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotAdapter.ts around line 2264:
In `respondToRequest`, after resolving `binding.deferred`, the `requestId` is not removed from `pendingPermissionBindings`. If called twice with the same `requestId`, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.
Evidence trail:
apps/server/src/provider/Layers/CopilotAdapter.ts lines 2248-2265 (respondToRequest function: no delete after Deferred.succeed at line 2264). Compare with lines 574-577 (settlePendingPermissionHandlers: calls .clear() after settling). Effect-TS Deferred.succeed returns Effect<boolean> — false if already done, no error thrown (see Effect-TS source/docs).

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[cursor]

Session teardown doesn't await pending event chain

High Severity

stopSessionInternal disconnects the SDK session and stops the client without first awaiting context.eventChain. Events still being processed asynchronously in the chain (including turn.completed and item.completed events) can race against or fail after the SDK resources are torn down. This likely explains the reported bug where sessions stop without surfacing final results. In contrast, startSession correctly awaits the chain at line 2180 with yield* Effect.promise(() => context.eventChain).

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotAdapter.ts#L2176-L2180

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[juliusmarminge]

A newer Copilot provider implementation, #3076, is active against the current provider architecture. Keeping this older provider branch would duplicate that effort.

This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.

[zortos293]

What Changed

• Added GitHub Copilot as a first-class provider using the official Copilot SDK.
• Wired Copilot through the server runtime, including provider detection, auth/status reporting, model discovery, session startup/resume, turn sending, request handling, and event streaming.
• Added Copilot-backed git text generation for commit messages, PR content, branch names, and thread titles.
• Added Copilot to shared contracts/settings so it behaves like the existing providers for model selection, reasoning options, defaults, and persisted settings.
• Updated the web app so Copilot appears in the provider/model dropdowns, settings panels, custom model management, composer state, and git writing model selection.

Why

T3 Code already supports multiple agent providers, but it did not have GitHub Copilot support. This change adds Copilot end to end in the same shape as the other providers instead of treating it as a one-off integration.

That keeps the UX and server behavior consistent: users can configure Copilot in settings, select Copilot models from the same pickers, use it for git text generation, and rely on the same persistence and runtime flows that already exist for other providers. Using the official SDK also keeps the integration aligned with GitHub’s supported protocol and model discovery/auth flows.

UI Changes

• Added Copilot to the provider picker.
• Added a Copilot settings section with binary path, server URL, and custom model configuration.
• Added Copilot to the git writing model picker and traits handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

High Risk
Adds a new first-class provider with complex session/event handling and introduces the @github/copilot-sdk runtime dependency, so failures/auth/model discovery issues could impact provider startup and chat/runtime flows.

Overview
Adds GitHub Copilot as a first-class provider end-to-end. The server now includes a new CopilotDriver registered in BUILT_IN_DRIVERS, a Copilot SDK runtime wrapper (copilotRuntime.ts) for auth/status/model probing, and a full CopilotAdapter that starts/resumes sessions, translates Copilot SDK events into provider runtime events (turn lifecycle, streaming deltas, tool execution, permissions/user-input), and hardens error/cleanup behavior.

Adds Copilot-backed git text generation (CopilotTextGeneration.ts) for commit messages/PR content/branch names/thread titles with pooled SDK clients and idle shutdown. Updates shared contracts/settings to include CopilotSettings, provider defaults/aliases/display names, and extends runtime raw event sources; the web app surfaces Copilot in provider pickers/settings/icons and removes the “coming soon” placeholder when a real Copilot instance exists. Includes extensive new tests covering adapter behavior, provider probe errors, and text-generation client reuse.

^{Reviewed by Cursor Bugbot for commit 2a55f8a. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add GitHub Copilot as a built-in provider for chat and text generation

• Adds a full CopilotDriver and CopilotAdapter that integrate with @github/copilot-sdk to support chat sessions, permission handling, and runtime event translation.
• Adds makeCopilotTextGeneration to generate commit messages, PR content, branch names, and thread titles via Copilot models using structured JSON outputs and a shared client pool.
• Adds checkCopilotProviderStatus to periodically probe the Copilot SDK for auth state, available models, and version info.
• Updates the settings UI, model picker, and provider icon mapping to treat Copilot as a first-class provider, removing the "Coming soon" placeholder.
• Risk: introduces a new runtime dependency @github/copilot-sdk@^0.2.2 and spawns external CLI processes; probe failures are surfaced as provider errors rather than silently ignored.

^{Macroscope summarized d464878.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 6417f1bb-b9f1-4115-890c-8459048c5942

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR adds a new GitHub Copilot provider integration with ~4500 lines of new code, external SDK dependencies, and complex session management. New feature additions with this scope require human review. Additionally, an unresolved high-severity comment identifies a potential race condition in session teardown that could cause lost events.

^{You can customize Macroscope's approvability policy. Learn more.}

[zortos293]

This needs to be tested if the desktop app is working fine with Copilot

[brrock]

Because julius plumbed in ACP can't we just use ACP, I guess the copilot sdk has copilot specific stuff

[cursor]

Copilot enabled by default causes unwanted CLI spawns

Medium Severity

CopilotSettings defaults enabled to true, meaning every existing user who upgrades will have Copilot auto-enabled. Combined with the 1-hour COPILOT_REFRESH_INTERVAL, this will repeatedly spawn the bundled Copilot CLI binary, attempt auth checks, and fail for the majority of users who have no GitHub Copilot subscription or auth configured. Unlike Codex/Claude/OpenCode which are the app's core providers, Copilot is a newly added optional integration — defaulting to false (like Cursor does) would avoid unnecessary process spawns and error noise on every refresh cycle.

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotProvider.ts#L18-L19

^{Reviewed by Cursor Bugbot for commit c9b851217439d17fbbe96d68b3f89077440f3446. Configure here.}

[rgembalik]

I am not a maintainer, but I did couple of local tests. There were few cases where session stopped without showing final results message. I don't know if this is upstream bug, or something related to the PR (currently I have only copilot license so it's hard to test against other providers). After asking, I got a response that the results were there, but probably didn't show on my end.

[zortos293]

i'l look into this

[brrock]

conflicts btw

[zortos293]

conflicts btw

imma look at it tmr 👍

[macroscopeapp]

🟢 LowLayers/CopilotProvider.ts:61

The checkedAt timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when checkCopilotProviderStatus was first invoked. Since makeManagedServerProvider re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.

 if (!input.settings.enabled) {
return Effect.succeed(makePendingCopilotProvider(input.settings));
}
- const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const fallback = (cause: unknown, version: string | null = null) => {
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const failure = formatCopilotProbeError({
cause,
settings: input.settings,
@@ -92,6 +92,7 @@
});
};
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
return Effect.acquireUseRelease(

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotProvider.ts around lines 61-147:
The `checkedAt` timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when `checkCopilotProviderStatus` was first invoked. Since `makeManagedServerProvider` re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.
Evidence trail:
apps/server/src/provider/Layers/CopilotProvider.ts lines 61-70 (checkedAt captured eagerly outside Effect), lines 95-149 (Effect.acquireUseRelease returned, closing over checkedAt). apps/server/src/provider/Drivers/CopilotDriver.ts lines 92-95 (checkCopilotProviderStatus called once, Effect passed as checkProvider). apps/server/src/provider/makeManagedServerProvider.ts lines 127-130 (input.checkProvider re-executed in applySnapshotBase), lines 163-168 (forever loop re-running refreshSnapshot on each interval).

[macroscopeapp]

🟢 LowLayers/CopilotAdapter.ts:2264

In respondToRequest, after resolving binding.deferred, the requestId is not removed from pendingPermissionBindings. If called twice with the same requestId, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.

- yield* Deferred.succeed(binding.deferred, result);+ yield* Deferred.succeed(binding.deferred, result);+ context.pendingPermissionBindings.delete(requestId);

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotAdapter.ts around line 2264:
In `respondToRequest`, after resolving `binding.deferred`, the `requestId` is not removed from `pendingPermissionBindings`. If called twice with the same `requestId`, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.
Evidence trail:
apps/server/src/provider/Layers/CopilotAdapter.ts lines 2248-2265 (respondToRequest function: no delete after Deferred.succeed at line 2264). Compare with lines 574-577 (settlePendingPermissionHandlers: calls .clear() after settling). Effect-TS Deferred.succeed returns Effect<boolean> — false if already done, no error thrown (see Effect-TS source/docs).

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[cursor]

Session teardown doesn't await pending event chain

High Severity

stopSessionInternal disconnects the SDK session and stops the client without first awaiting context.eventChain. Events still being processed asynchronously in the chain (including turn.completed and item.completed events) can race against or fail after the SDK resources are torn down. This likely explains the reported bug where sessions stop without surfacing final results. In contrast, startSession correctly awaits the chain at line 2180 with yield* Effect.promise(() => context.eventChain).

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotAdapter.ts#L2176-L2180

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[juliusmarminge]

A newer Copilot provider implementation, #3076, is active against the current provider architecture. Keeping this older provider branch would duplicate that effort.

This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.

[zortos293]

What Changed

• Added GitHub Copilot as a first-class provider using the official Copilot SDK.
• Wired Copilot through the server runtime, including provider detection, auth/status reporting, model discovery, session startup/resume, turn sending, request handling, and event streaming.
• Added Copilot-backed git text generation for commit messages, PR content, branch names, and thread titles.
• Added Copilot to shared contracts/settings so it behaves like the existing providers for model selection, reasoning options, defaults, and persisted settings.
• Updated the web app so Copilot appears in the provider/model dropdowns, settings panels, custom model management, composer state, and git writing model selection.

Why

T3 Code already supports multiple agent providers, but it did not have GitHub Copilot support. This change adds Copilot end to end in the same shape as the other providers instead of treating it as a one-off integration.

That keeps the UX and server behavior consistent: users can configure Copilot in settings, select Copilot models from the same pickers, use it for git text generation, and rely on the same persistence and runtime flows that already exist for other providers. Using the official SDK also keeps the integration aligned with GitHub’s supported protocol and model discovery/auth flows.

UI Changes

• Added Copilot to the provider picker.
• Added a Copilot settings section with binary path, server URL, and custom model configuration.
• Added Copilot to the git writing model picker and traits handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

High Risk
Adds a new first-class provider with complex session/event handling and introduces the @github/copilot-sdk runtime dependency, so failures/auth/model discovery issues could impact provider startup and chat/runtime flows.

Overview
Adds GitHub Copilot as a first-class provider end-to-end. The server now includes a new CopilotDriver registered in BUILT_IN_DRIVERS, a Copilot SDK runtime wrapper (copilotRuntime.ts) for auth/status/model probing, and a full CopilotAdapter that starts/resumes sessions, translates Copilot SDK events into provider runtime events (turn lifecycle, streaming deltas, tool execution, permissions/user-input), and hardens error/cleanup behavior.

Adds Copilot-backed git text generation (CopilotTextGeneration.ts) for commit messages/PR content/branch names/thread titles with pooled SDK clients and idle shutdown. Updates shared contracts/settings to include CopilotSettings, provider defaults/aliases/display names, and extends runtime raw event sources; the web app surfaces Copilot in provider pickers/settings/icons and removes the “coming soon” placeholder when a real Copilot instance exists. Includes extensive new tests covering adapter behavior, provider probe errors, and text-generation client reuse.

^{Reviewed by Cursor Bugbot for commit 2a55f8a. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add GitHub Copilot as a built-in provider for chat and text generation

• Adds a full CopilotDriver and CopilotAdapter that integrate with @github/copilot-sdk to support chat sessions, permission handling, and runtime event translation.
• Adds makeCopilotTextGeneration to generate commit messages, PR content, branch names, and thread titles via Copilot models using structured JSON outputs and a shared client pool.
• Adds checkCopilotProviderStatus to periodically probe the Copilot SDK for auth state, available models, and version info.
• Updates the settings UI, model picker, and provider icon mapping to treat Copilot as a first-class provider, removing the "Coming soon" placeholder.
• Risk: introduces a new runtime dependency @github/copilot-sdk@^0.2.2 and spawns external CLI processes; probe failures are surfaced as provider errors rather than silently ignored.

^{Macroscope summarized d464878.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 6417f1bb-b9f1-4115-890c-8459048c5942

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR adds a new GitHub Copilot provider integration with ~4500 lines of new code, external SDK dependencies, and complex session management. New feature additions with this scope require human review. Additionally, an unresolved high-severity comment identifies a potential race condition in session teardown that could cause lost events.

^{You can customize Macroscope's approvability policy. Learn more.}

[zortos293]

This needs to be tested if the desktop app is working fine with Copilot

[brrock]

Because julius plumbed in ACP can't we just use ACP, I guess the copilot sdk has copilot specific stuff

[cursor]

Copilot enabled by default causes unwanted CLI spawns

Medium Severity

CopilotSettings defaults enabled to true, meaning every existing user who upgrades will have Copilot auto-enabled. Combined with the 1-hour COPILOT_REFRESH_INTERVAL, this will repeatedly spawn the bundled Copilot CLI binary, attempt auth checks, and fail for the majority of users who have no GitHub Copilot subscription or auth configured. Unlike Codex/Claude/OpenCode which are the app's core providers, Copilot is a newly added optional integration — defaulting to false (like Cursor does) would avoid unnecessary process spawns and error noise on every refresh cycle.

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotProvider.ts#L18-L19

^{Reviewed by Cursor Bugbot for commit c9b851217439d17fbbe96d68b3f89077440f3446. Configure here.}

[rgembalik]

I am not a maintainer, but I did couple of local tests. There were few cases where session stopped without showing final results message. I don't know if this is upstream bug, or something related to the PR (currently I have only copilot license so it's hard to test against other providers). After asking, I got a response that the results were there, but probably didn't show on my end.

[zortos293]

i'l look into this

[brrock]

conflicts btw

[zortos293]

conflicts btw

imma look at it tmr 👍

[macroscopeapp]

🟢 LowLayers/CopilotProvider.ts:61

The checkedAt timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when checkCopilotProviderStatus was first invoked. Since makeManagedServerProvider re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.

 if (!input.settings.enabled) {
return Effect.succeed(makePendingCopilotProvider(input.settings));
}
- const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const fallback = (cause: unknown, version: string | null = null) => {
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const failure = formatCopilotProbeError({
cause,
settings: input.settings,
@@ -92,6 +92,7 @@
});
};
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
return Effect.acquireUseRelease(

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotProvider.ts around lines 61-147:
The `checkedAt` timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when `checkCopilotProviderStatus` was first invoked. Since `makeManagedServerProvider` re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.
Evidence trail:
apps/server/src/provider/Layers/CopilotProvider.ts lines 61-70 (checkedAt captured eagerly outside Effect), lines 95-149 (Effect.acquireUseRelease returned, closing over checkedAt). apps/server/src/provider/Drivers/CopilotDriver.ts lines 92-95 (checkCopilotProviderStatus called once, Effect passed as checkProvider). apps/server/src/provider/makeManagedServerProvider.ts lines 127-130 (input.checkProvider re-executed in applySnapshotBase), lines 163-168 (forever loop re-running refreshSnapshot on each interval).

[macroscopeapp]

🟢 LowLayers/CopilotAdapter.ts:2264

In respondToRequest, after resolving binding.deferred, the requestId is not removed from pendingPermissionBindings. If called twice with the same requestId, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.

- yield* Deferred.succeed(binding.deferred, result);+ yield* Deferred.succeed(binding.deferred, result);+ context.pendingPermissionBindings.delete(requestId);

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotAdapter.ts around line 2264:
In `respondToRequest`, after resolving `binding.deferred`, the `requestId` is not removed from `pendingPermissionBindings`. If called twice with the same `requestId`, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.
Evidence trail:
apps/server/src/provider/Layers/CopilotAdapter.ts lines 2248-2265 (respondToRequest function: no delete after Deferred.succeed at line 2264). Compare with lines 574-577 (settlePendingPermissionHandlers: calls .clear() after settling). Effect-TS Deferred.succeed returns Effect<boolean> — false if already done, no error thrown (see Effect-TS source/docs).

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[cursor]

Session teardown doesn't await pending event chain

High Severity

stopSessionInternal disconnects the SDK session and stops the client without first awaiting context.eventChain. Events still being processed asynchronously in the chain (including turn.completed and item.completed events) can race against or fail after the SDK resources are torn down. This likely explains the reported bug where sessions stop without surfacing final results. In contrast, startSession correctly awaits the chain at line 2180 with yield* Effect.promise(() => context.eventChain).

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotAdapter.ts#L2176-L2180

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[juliusmarminge]

A newer Copilot provider implementation, #3076, is active against the current provider architecture. Keeping this older provider branch would duplicate that effort.

This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.

[zortos293]

What Changed

• Added GitHub Copilot as a first-class provider using the official Copilot SDK.
• Wired Copilot through the server runtime, including provider detection, auth/status reporting, model discovery, session startup/resume, turn sending, request handling, and event streaming.
• Added Copilot-backed git text generation for commit messages, PR content, branch names, and thread titles.
• Added Copilot to shared contracts/settings so it behaves like the existing providers for model selection, reasoning options, defaults, and persisted settings.
• Updated the web app so Copilot appears in the provider/model dropdowns, settings panels, custom model management, composer state, and git writing model selection.

Why

T3 Code already supports multiple agent providers, but it did not have GitHub Copilot support. This change adds Copilot end to end in the same shape as the other providers instead of treating it as a one-off integration.

That keeps the UX and server behavior consistent: users can configure Copilot in settings, select Copilot models from the same pickers, use it for git text generation, and rely on the same persistence and runtime flows that already exist for other providers. Using the official SDK also keeps the integration aligned with GitHub’s supported protocol and model discovery/auth flows.

UI Changes

• Added Copilot to the provider picker.
• Added a Copilot settings section with binary path, server URL, and custom model configuration.
• Added Copilot to the git writing model picker and traits handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

High Risk
Adds a new first-class provider with complex session/event handling and introduces the @github/copilot-sdk runtime dependency, so failures/auth/model discovery issues could impact provider startup and chat/runtime flows.

Overview
Adds GitHub Copilot as a first-class provider end-to-end. The server now includes a new CopilotDriver registered in BUILT_IN_DRIVERS, a Copilot SDK runtime wrapper (copilotRuntime.ts) for auth/status/model probing, and a full CopilotAdapter that starts/resumes sessions, translates Copilot SDK events into provider runtime events (turn lifecycle, streaming deltas, tool execution, permissions/user-input), and hardens error/cleanup behavior.

Adds Copilot-backed git text generation (CopilotTextGeneration.ts) for commit messages/PR content/branch names/thread titles with pooled SDK clients and idle shutdown. Updates shared contracts/settings to include CopilotSettings, provider defaults/aliases/display names, and extends runtime raw event sources; the web app surfaces Copilot in provider pickers/settings/icons and removes the “coming soon” placeholder when a real Copilot instance exists. Includes extensive new tests covering adapter behavior, provider probe errors, and text-generation client reuse.

^{Reviewed by Cursor Bugbot for commit 2a55f8a. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add GitHub Copilot as a built-in provider for chat and text generation

• Adds a full CopilotDriver and CopilotAdapter that integrate with @github/copilot-sdk to support chat sessions, permission handling, and runtime event translation.
• Adds makeCopilotTextGeneration to generate commit messages, PR content, branch names, and thread titles via Copilot models using structured JSON outputs and a shared client pool.
• Adds checkCopilotProviderStatus to periodically probe the Copilot SDK for auth state, available models, and version info.
• Updates the settings UI, model picker, and provider icon mapping to treat Copilot as a first-class provider, removing the "Coming soon" placeholder.
• Risk: introduces a new runtime dependency @github/copilot-sdk@^0.2.2 and spawns external CLI processes; probe failures are surfaced as provider errors rather than silently ignored.

^{Macroscope summarized d464878.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 6417f1bb-b9f1-4115-890c-8459048c5942

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR adds a new GitHub Copilot provider integration with ~4500 lines of new code, external SDK dependencies, and complex session management. New feature additions with this scope require human review. Additionally, an unresolved high-severity comment identifies a potential race condition in session teardown that could cause lost events.

^{You can customize Macroscope's approvability policy. Learn more.}

[zortos293]

This needs to be tested if the desktop app is working fine with Copilot

[brrock]

Because julius plumbed in ACP can't we just use ACP, I guess the copilot sdk has copilot specific stuff

[cursor]

Copilot enabled by default causes unwanted CLI spawns

Medium Severity

CopilotSettings defaults enabled to true, meaning every existing user who upgrades will have Copilot auto-enabled. Combined with the 1-hour COPILOT_REFRESH_INTERVAL, this will repeatedly spawn the bundled Copilot CLI binary, attempt auth checks, and fail for the majority of users who have no GitHub Copilot subscription or auth configured. Unlike Codex/Claude/OpenCode which are the app's core providers, Copilot is a newly added optional integration — defaulting to false (like Cursor does) would avoid unnecessary process spawns and error noise on every refresh cycle.

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotProvider.ts#L18-L19

^{Reviewed by Cursor Bugbot for commit c9b851217439d17fbbe96d68b3f89077440f3446. Configure here.}

[rgembalik]

I am not a maintainer, but I did couple of local tests. There were few cases where session stopped without showing final results message. I don't know if this is upstream bug, or something related to the PR (currently I have only copilot license so it's hard to test against other providers). After asking, I got a response that the results were there, but probably didn't show on my end.

[zortos293]

i'l look into this

[brrock]

conflicts btw

[zortos293]

conflicts btw

imma look at it tmr 👍

[macroscopeapp]

🟢 LowLayers/CopilotProvider.ts:61

The checkedAt timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when checkCopilotProviderStatus was first invoked. Since makeManagedServerProvider re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.

 if (!input.settings.enabled) {
return Effect.succeed(makePendingCopilotProvider(input.settings));
}
- const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const fallback = (cause: unknown, version: string | null = null) => {
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const failure = formatCopilotProbeError({
cause,
settings: input.settings,
@@ -92,6 +92,7 @@
});
};
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
return Effect.acquireUseRelease(

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotProvider.ts around lines 61-147:
The `checkedAt` timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when `checkCopilotProviderStatus` was first invoked. Since `makeManagedServerProvider` re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.
Evidence trail:
apps/server/src/provider/Layers/CopilotProvider.ts lines 61-70 (checkedAt captured eagerly outside Effect), lines 95-149 (Effect.acquireUseRelease returned, closing over checkedAt). apps/server/src/provider/Drivers/CopilotDriver.ts lines 92-95 (checkCopilotProviderStatus called once, Effect passed as checkProvider). apps/server/src/provider/makeManagedServerProvider.ts lines 127-130 (input.checkProvider re-executed in applySnapshotBase), lines 163-168 (forever loop re-running refreshSnapshot on each interval).

[macroscopeapp]

🟢 LowLayers/CopilotAdapter.ts:2264

In respondToRequest, after resolving binding.deferred, the requestId is not removed from pendingPermissionBindings. If called twice with the same requestId, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.

- yield* Deferred.succeed(binding.deferred, result);+ yield* Deferred.succeed(binding.deferred, result);+ context.pendingPermissionBindings.delete(requestId);

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotAdapter.ts around line 2264:
In `respondToRequest`, after resolving `binding.deferred`, the `requestId` is not removed from `pendingPermissionBindings`. If called twice with the same `requestId`, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.
Evidence trail:
apps/server/src/provider/Layers/CopilotAdapter.ts lines 2248-2265 (respondToRequest function: no delete after Deferred.succeed at line 2264). Compare with lines 574-577 (settlePendingPermissionHandlers: calls .clear() after settling). Effect-TS Deferred.succeed returns Effect<boolean> — false if already done, no error thrown (see Effect-TS source/docs).

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[cursor]

Session teardown doesn't await pending event chain

High Severity

stopSessionInternal disconnects the SDK session and stops the client without first awaiting context.eventChain. Events still being processed asynchronously in the chain (including turn.completed and item.completed events) can race against or fail after the SDK resources are torn down. This likely explains the reported bug where sessions stop without surfacing final results. In contrast, startSession correctly awaits the chain at line 2180 with yield* Effect.promise(() => context.eventChain).

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotAdapter.ts#L2176-L2180

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[juliusmarminge]

A newer Copilot provider implementation, #3076, is active against the current provider architecture. Keeping this older provider branch would duplicate that effort.

This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.

[zortos293]

What Changed

• Added GitHub Copilot as a first-class provider using the official Copilot SDK.
• Wired Copilot through the server runtime, including provider detection, auth/status reporting, model discovery, session startup/resume, turn sending, request handling, and event streaming.
• Added Copilot-backed git text generation for commit messages, PR content, branch names, and thread titles.
• Added Copilot to shared contracts/settings so it behaves like the existing providers for model selection, reasoning options, defaults, and persisted settings.
• Updated the web app so Copilot appears in the provider/model dropdowns, settings panels, custom model management, composer state, and git writing model selection.

Why

T3 Code already supports multiple agent providers, but it did not have GitHub Copilot support. This change adds Copilot end to end in the same shape as the other providers instead of treating it as a one-off integration.

That keeps the UX and server behavior consistent: users can configure Copilot in settings, select Copilot models from the same pickers, use it for git text generation, and rely on the same persistence and runtime flows that already exist for other providers. Using the official SDK also keeps the integration aligned with GitHub’s supported protocol and model discovery/auth flows.

UI Changes

• Added Copilot to the provider picker.
• Added a Copilot settings section with binary path, server URL, and custom model configuration.
• Added Copilot to the git writing model picker and traits handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

High Risk
Adds a new first-class provider with complex session/event handling and introduces the @github/copilot-sdk runtime dependency, so failures/auth/model discovery issues could impact provider startup and chat/runtime flows.

Overview
Adds GitHub Copilot as a first-class provider end-to-end. The server now includes a new CopilotDriver registered in BUILT_IN_DRIVERS, a Copilot SDK runtime wrapper (copilotRuntime.ts) for auth/status/model probing, and a full CopilotAdapter that starts/resumes sessions, translates Copilot SDK events into provider runtime events (turn lifecycle, streaming deltas, tool execution, permissions/user-input), and hardens error/cleanup behavior.

Adds Copilot-backed git text generation (CopilotTextGeneration.ts) for commit messages/PR content/branch names/thread titles with pooled SDK clients and idle shutdown. Updates shared contracts/settings to include CopilotSettings, provider defaults/aliases/display names, and extends runtime raw event sources; the web app surfaces Copilot in provider pickers/settings/icons and removes the “coming soon” placeholder when a real Copilot instance exists. Includes extensive new tests covering adapter behavior, provider probe errors, and text-generation client reuse.

^{Reviewed by Cursor Bugbot for commit 2a55f8a. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add GitHub Copilot as a built-in provider for chat and text generation

• Adds a full CopilotDriver and CopilotAdapter that integrate with @github/copilot-sdk to support chat sessions, permission handling, and runtime event translation.
• Adds makeCopilotTextGeneration to generate commit messages, PR content, branch names, and thread titles via Copilot models using structured JSON outputs and a shared client pool.
• Adds checkCopilotProviderStatus to periodically probe the Copilot SDK for auth state, available models, and version info.
• Updates the settings UI, model picker, and provider icon mapping to treat Copilot as a first-class provider, removing the "Coming soon" placeholder.
• Risk: introduces a new runtime dependency @github/copilot-sdk@^0.2.2 and spawns external CLI processes; probe failures are surfaced as provider errors rather than silently ignored.

^{Macroscope summarized d464878.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 6417f1bb-b9f1-4115-890c-8459048c5942

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR adds a new GitHub Copilot provider integration with ~4500 lines of new code, external SDK dependencies, and complex session management. New feature additions with this scope require human review. Additionally, an unresolved high-severity comment identifies a potential race condition in session teardown that could cause lost events.

^{You can customize Macroscope's approvability policy. Learn more.}

[zortos293]

This needs to be tested if the desktop app is working fine with Copilot

[brrock]

Because julius plumbed in ACP can't we just use ACP, I guess the copilot sdk has copilot specific stuff

[cursor]

Copilot enabled by default causes unwanted CLI spawns

Medium Severity

CopilotSettings defaults enabled to true, meaning every existing user who upgrades will have Copilot auto-enabled. Combined with the 1-hour COPILOT_REFRESH_INTERVAL, this will repeatedly spawn the bundled Copilot CLI binary, attempt auth checks, and fail for the majority of users who have no GitHub Copilot subscription or auth configured. Unlike Codex/Claude/OpenCode which are the app's core providers, Copilot is a newly added optional integration — defaulting to false (like Cursor does) would avoid unnecessary process spawns and error noise on every refresh cycle.

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotProvider.ts#L18-L19

^{Reviewed by Cursor Bugbot for commit c9b851217439d17fbbe96d68b3f89077440f3446. Configure here.}

[rgembalik]

I am not a maintainer, but I did couple of local tests. There were few cases where session stopped without showing final results message. I don't know if this is upstream bug, or something related to the PR (currently I have only copilot license so it's hard to test against other providers). After asking, I got a response that the results were there, but probably didn't show on my end.

[zortos293]

i'l look into this

[brrock]

conflicts btw

[zortos293]

conflicts btw

imma look at it tmr 👍

[macroscopeapp]

🟢 LowLayers/CopilotProvider.ts:61

The checkedAt timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when checkCopilotProviderStatus was first invoked. Since makeManagedServerProvider re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.

 if (!input.settings.enabled) {
return Effect.succeed(makePendingCopilotProvider(input.settings));
}
- const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const fallback = (cause: unknown, version: string | null = null) => {
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
const failure = formatCopilotProbeError({
cause,
settings: input.settings,
@@ -92,6 +92,7 @@
});
};
+ const checkedAt = DateTime.formatIso(DateTime.nowUnsafe());
return Effect.acquireUseRelease(

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotProvider.ts around lines 61-147:
The `checkedAt` timestamp is captured at function call time on line 70, so every execution of the returned Effect reports the same stale timestamp from when `checkCopilotProviderStatus` was first invoked. Since `makeManagedServerProvider` re-executes this Effect on each refresh interval, all subsequent checks incorrectly show the original timestamp rather than when each check actually occurred.
Evidence trail:
apps/server/src/provider/Layers/CopilotProvider.ts lines 61-70 (checkedAt captured eagerly outside Effect), lines 95-149 (Effect.acquireUseRelease returned, closing over checkedAt). apps/server/src/provider/Drivers/CopilotDriver.ts lines 92-95 (checkCopilotProviderStatus called once, Effect passed as checkProvider). apps/server/src/provider/makeManagedServerProvider.ts lines 127-130 (input.checkProvider re-executed in applySnapshotBase), lines 163-168 (forever loop re-running refreshSnapshot on each interval).

[macroscopeapp]

🟢 LowLayers/CopilotAdapter.ts:2264

In respondToRequest, after resolving binding.deferred, the requestId is not removed from pendingPermissionBindings. If called twice with the same requestId, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.

- yield* Deferred.succeed(binding.deferred, result);+ yield* Deferred.succeed(binding.deferred, result);+ context.pendingPermissionBindings.delete(requestId);

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/provider/Layers/CopilotAdapter.ts around line 2264:
In `respondToRequest`, after resolving `binding.deferred`, the `requestId` is not removed from `pendingPermissionBindings`. If called twice with the same `requestId`, the second call silently succeeds instead of returning an error, which can mask client bugs or race conditions. Consider deleting the binding immediately after resolving it.
Evidence trail:
apps/server/src/provider/Layers/CopilotAdapter.ts lines 2248-2265 (respondToRequest function: no delete after Deferred.succeed at line 2264). Compare with lines 574-577 (settlePendingPermissionHandlers: calls .clear() after settling). Effect-TS Deferred.succeed returns Effect<boolean> — false if already done, no error thrown (see Effect-TS source/docs).

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[cursor]

Session teardown doesn't await pending event chain

High Severity

stopSessionInternal disconnects the SDK session and stops the client without first awaiting context.eventChain. Events still being processed asynchronously in the chain (including turn.completed and item.completed events) can race against or fail after the SDK resources are torn down. This likely explains the reported bug where sessions stop without surfacing final results. In contrast, startSession correctly awaits the chain at line 2180 with yield* Effect.promise(() => context.eventChain).

Additional Locations (1)

• apps/server/src/provider/Layers/CopilotAdapter.ts#L2176-L2180

^{Reviewed by Cursor Bugbot for commit d464878. Configure here.}

[juliusmarminge]

A newer Copilot provider implementation, #3076, is active against the current provider architecture. Keeping this older provider branch would duplicate that effort.

This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.