ProtectedclientProtectedclientProtected ReadonlycliProtected ReadonlycredentialProtected ReadonlyenvProtected ReadonlyloggerProtected ReadonlysdkProtectedcreateBuilds the options of the CopilotClient.
The token of this application is passed explicitly and the resolution of a logged-in user is switched off, so that the runtime cannot fall back to credentials this application does not own.
The CLI is passed explicitly as well, see CopilotCliLocator: the SDK would otherwise look
for the JavaScript entry point of a platform package installed next to itself and spawn it with
process.execPath, which is the Electron binary rather than Node.js in an Electron application.
The runtime is configured in empty mode rather than in the copilot-cli mode the SDK defaults
to. That mode brings the ambient behaviour of the CLI along, which the SDK documents as unsuitable
for an application serving requests on a backend: instructions and skills found on the host,
session and memory stores, host git operations and plugins. Theia drives the conversation itself
and declares the tools of each request, so none of that applies, and empty mode additionally
keeps the runtime away from the system keychain. Its two requirements are met here, a persistence
location (getCopilotHome) and an explicit tool list per session.
ProtectedcreateReturns the environment for the runtime process.
Tokens from the environment are removed: the runtime accepts them even when a token is passed explicitly, and they are not a sign-in of this application. The GitHub host is taken from the credentials, so that the runtime always talks to the deployment that was signed in to.
The Copilot API endpoint is deliberately not set: the runtime resolves the one belonging to the
subscription from the token, including for Business and Enterprise seats. The environment of the
backend is inherited as-is, so an operator can still override it with COPILOT_API_URL should
that resolution ever fail for a deployment.
ProtectedenrichReplaces the bare authorization failure of the Copilot runtime with an explanation of the possible causes, because the runtime only reports that the feature is not authorized.
Returns a started CopilotClient, creating (or recreating, if the configuration changed) one on demand.
ProtectedgetProtectedgetThe Copilot home the runtime is pointed at, below the configuration directory of Theia.
Requests are served in sessions that the runtime persists in its home, and the default home is the one the user's own Copilot CLI uses. Prompts sent from Theia would end up listed among the conversations the user started themselves, so this application keeps its own.
Lists the model IDs available to the authenticated user via the Copilot CLI. Because the CLI runs under an entitled identity, this returns the full current model lineup rather than the baseline set that the direct REST API exposes to an unentitled OAuth app.
ProtectedrecreateStops and clears the current client. Safe to call when no client exists.
ProtectedstopStops the CLI when the container this provider lives in goes away, which happens when the frontend connection it belongs to is closed.
A closing connection unbinds its container, and unbinding runs @preDestroy rather than
dispose. Without this hook the CLI of every closed connection would keep running for the rest
of the lifetime of the backend.
Manages the lifecycle of a CopilotClient, which spawns and talks to the official Copilot CLI over JSON-RPC.
The runtime is given the token this application holds, and nothing else: credentials the CLI could otherwise pick up on its own, from the environment or from the sign-in of the GitHub CLI, are not a sign-in of this application and are deliberately kept out of reach. The token is established by CopilotCliAuthProvider and kept in CopilotCredentialStore.
A single client is started lazily and shared for the lifetime of the (connection-scoped) backend container. It is recreated when the host configuration changes.
Note: this provider is bound in the per-connection container, so each frontend connection runs its own CLI process, authenticated with the credentials of the backend host. This is not suitable for multi-user backend deployments, where every connected frontend would share a single identity.