See PR #4249
The copilot harness (GitHub Copilot SDK, in-process) is part of omnigent, but it is not reachable from the product surface: no entry in the harness picker, no model selection, no GitHub Enterprise support, and readiness rejects machines that authenticate via copilot login. For organizations running Copilot seats, often on GitHub Enterprise with data residency, that makes the harness effectively unusable today.
I have a working implementation and would like to contribute it. Opening this issue first per CONTRIBUTING to align on scope; the PR with full details, screenshots, and testing notes: #4249.
What it adds:
- Copilot in the harness picker. A seeded
copilot builtin chat agent plus a registry entry alongside Claude Code and Codex. Copilot is the first chat-mode entry (SDK in-process, no terminal to wrap), so the registry gains an explicit sessionMode: "chat"; chat entries bind by agent name only and never classify sessions as terminal sessions.
- Live, policy-filtered model catalog. The host answers the pre-launch model-options probe via
CopilotClient.list_models(), so the gear modal shows exactly the models the signed-in seat may use, enterprise policy included. Reasoning efforts come per model from supported_reasoning_efforts; the effort select renders only the selected model's ladder and hides for models without one.
-
GitHub Enterprise host in omnigent setup. The Copilot CLI validates a token against api.github.com unless COPILOT_GH_HOST names the tenant host, and that env var does not survive the daemon/runner env allowlists. The host becomes a config value (copilot.gh_host), set once in the Copilot setup drill-in and threaded to the harness spawn env by the runner. GH_HOST itself is never touched.
-
Readiness accepts the Copilot CLI login. Previously only a resolvable token counted, so a machine authenticated via copilot login was rejected with 412 even though sessions run fine on the stored credential. On Enterprise seats this is the auth path that works best, because the CLI login carries its own host.
Design decisions worth flagging for review:
- The copilot builtin is seeded by a dedicated
_ensure_default_copilot_agent rather than the NATIVE_CODING_AGENTS table, because the table requires a native provider row with a materialize_agent_spec hook, which the SDK-in-process harness does not have.
- The picker entry carries no
fullySupported flag: Copilot starts under "More" and surfaces through the recent-harness mechanic once used.
COPILOT_EFFORTS widens to the CLI's full vocabulary (none|minimal|low|medium|high|xhigh|max); per-model subsets are enforced by the backend and mirrored in the UI.
Everything is implemented on top of current main and verified end to end against a live GitHub Enterprise data-residency seat.
See PR #4249
The copilot harness (GitHub Copilot SDK, in-process) is part of omnigent, but it is not reachable from the product surface: no entry in the harness picker, no model selection, no GitHub Enterprise support, and readiness rejects machines that authenticate via
copilot login. For organizations running Copilot seats, often on GitHub Enterprise with data residency, that makes the harness effectively unusable today.I have a working implementation and would like to contribute it. Opening this issue first per CONTRIBUTING to align on scope; the PR with full details, screenshots, and testing notes: #4249.
What it adds:
copilotbuiltin chat agent plus a registry entry alongside Claude Code and Codex. Copilot is the first chat-mode entry (SDK in-process, no terminal to wrap), so the registry gains an explicitsessionMode: "chat"; chat entries bind by agent name only and never classify sessions as terminal sessions.CopilotClient.list_models(), so the gear modal shows exactly the models the signed-in seat may use, enterprise policy included. Reasoning efforts come per model fromsupported_reasoning_efforts; the effort select renders only the selected model's ladder and hides for models without one.GitHub Enterprise host in
omnigent setup. The Copilot CLI validates a token againstapi.github.comunlessCOPILOT_GH_HOSTnames the tenant host, and that env var does not survive the daemon/runner env allowlists. The host becomes a config value (copilot.gh_host), set once in the Copilot setup drill-in and threaded to the harness spawn env by the runner.GH_HOSTitself is never touched.Readiness accepts the Copilot CLI login. Previously only a resolvable token counted, so a machine authenticated via
copilot loginwas rejected with 412 even though sessions run fine on the stored credential. On Enterprise seats this is the auth path that works best, because the CLI login carries its own host.Design decisions worth flagging for review:
_ensure_default_copilot_agentrather than theNATIVE_CODING_AGENTStable, because the table requires a native provider row with amaterialize_agent_spechook, which the SDK-in-process harness does not have.fullySupportedflag: Copilot starts under "More" and surfaces through the recent-harness mechanic once used.COPILOT_EFFORTSwidens to the CLI's full vocabulary (none|minimal|low|medium|high|xhigh|max); per-model subsets are enforced by the backend and mirrored in the UI.Everything is implemented on top of current main and verified end to end against a live GitHub Enterprise data-residency seat.