Skip to content

Add GitHub Copilot CLI as a supported host #393

Closed

Description

@ridermw

Summary

The GitHub Copilot CLI went GA in February 2026 as a standalone binary (copilot), separate from the old gh copilot extension. It supports skill discovery via ~/.copilot/skills/ and has its own session storage at ~/.copilot/session-state/{id}/.

gstack already supports Claude Code, Codex, Gemini CLI, and Cursor. Copilot CLI fits the same pattern — it uses .agents/skills/ for repo-local discovery and has a global install path at ~/.copilot/skills/gstack.

What would Copilot support look like?

Based on the existing Codex pattern:

  • gen-skill-docs.ts: Add 'copilot' host type. Copilot shares .agents/skills/ output with Codex — only the global fallback path differs (~/.copilot/skills/gstack vs ~/.codex/skills/gstack).
  • setup: Add --host copilot with auto-detection via command -v copilot. Rewrite Codex output paths at install time via sed (same pattern as Kiro).
  • gstack-global-discover.ts: Add scanCopilot() for session discovery at ~/.copilot/session-state/.
  • Tests: Copilot E2E runner paralleling the Codex session runner, updated assertions in existing tests.
  • Docs: README, CONTRIBUTING, AGENTS.md updated to mention Copilot as a peer host.

No build pipeline changes needed — Copilot derives from Codex output at setup time. No architectural changes.

Copilot CLI facts

Aspect Value
Binary copilot (standalone, not gh copilot)
Install npm install -g @github/copilot (also: brew, winget, install script)
Config dir ~/.copilot/
Session data ~/.copilot/session-state/{session-id}/
Docs https://docs.github.com/copilot/how-tos/set-up/install-copilot-cli

Reference implementation

I've put together a working implementation in PR #396. 501 lines added across 14 files, follows the existing Codex/Kiro pattern exactly. Happy to close it if you'd prefer to implement this differently.

Related: #289 (host integration contract RFC) — this would be another concrete data point for that discussion.

Activity

  1. ridermw commented on Mar 25, 2026

    @ridermw
    ContributorAuthor

    I just pushed a smaller PR for this: #487 .

    It takes the minimal-support path by using Copilot CLI's documented .claude/skills compatibility instead of adding a new Copilot-specific host/generator path, but it also includes Copilot in session discovery for /retro global.

  2. arkar16 commented on Mar 28, 2026

    @arkar16

    Is this ready to implement and use? Thanks for making this a first-class option. Good to add more harnesses

  3. maskaravivek commented on Mar 30, 2026

    @maskaravivek

    Would be great if we could get one of the implementations merged, i use Copilot quite often and would love to use gstack with it.

  4. Thypari commented on Apr 22, 2026

    @Thypari

    Any updates on this?

  5. ganmuru commented on Apr 29, 2026

    @ganmuru

    Can someone look into this?

  6. rodneymhungu commented on Jun 5, 2026

    @rodneymhungu

    Reference branch (not a PR): main...rodneymhungu:gstack:copilot-cli-host-v1

    I have a small, portable take on Copilot CLI support, sharing it here to gauge interest before opening anything, given how many PRs on this have already been closed (including #487) and that #1852 and #396 are still open.

    The angle is deliberately minimal. Rather than wiring the full gstack runtime, browser daemon, and hook scripts into Copilot, it installs only seven advisory and review skills that work standalone: careful, freeze, guard, office-hours, plan-eng-review, review, cso. A host adapter softens runtime-only instructions into advisory prose, so nothing depends on bin/gstack-paths, the browse binary, or token handling. Browser- and runtime-backed skills (browse, qa, qa-only, pair-agent, open-gstack-browser, sidebar features) are explicitly deferred.

    It follows the existing declarative host pattern in docs/ADDING_A_HOST.md: one hosts/copilot.ts config plus a small adapter, with ./setup --host copilot copying gstack-<skill> folders into ~/.copilot/skills. The exclusion test is scoped to that install target, so deferred skills can still be discovered from a checkout's project skill folders but are never installed globally.

    Before investing further or sending a PR, is a portable v1 in this shape something you would consider merging? Happy to instead help move #1852 or #396 along if you would rather consolidate on one of those. Thanks for gstack.

  7. time-attack commented on Jul 15, 2026

    @time-attack
    Contributor

    @ridermw GitHub Copilot CLI support remains unresolved, and this issue is the primary place tracking that work.

  8. dgrant commented on Jul 22, 2026

    @dgrant
    Contributor

    Looks like #2323 was just created

  9. andrey-esipov commented on Jul 24, 2026

    @andrey-esipov
    Contributor

    Following up on @dgrant's pointer to #2323, with context on how it relates to the earlier attempts here.

    #2323 is a fresh implementation against the current host architecture, not a rebase of #396. It adds one declarative copilot host (hosts/copilot.ts) that covers both the standalone Copilot CLI and the desktop app project sessions, rather than deriving Copilot output from Codex at setup time via sed. That difference matters: gstack's host layer moved to declarative host definitions after #396 was written, so the sed-rewrite approach described in the issue body no longer matches how hosts are wired. Scope is +831/-87 across 19 files (head 0b41da9d), including a new test/copilot-host.test.ts and updated test/host-config.test.ts.

    Credit where it belongs: @ridermw opened #396 and #487 back in March and did the original legwork on the Copilot discovery paths and session storage layout. #2323 reaches the same goal through the current architecture, and I would rather see that prior work acknowledged than quietly replaced.

    On #396's status. It is at CONFLICTING / DIRTY with no commits since 2026-03-23 and no CI checks reported. @time-attack (Jul 15) and @dgrant (Jul 22) have both asked for it to be closed, with time-attack noting it "cannot be safely updated through a small rebase." I am not touching it, that is the maintainer's call, but it does mean there is currently no live PR for this other than #2323.

    One thing to know before reading #2323's checks. Seven eval shards plus report are red, and all of them are fork-secret injection rather than code defects. GitHub does not pass repository secrets to a pull_request from a fork, so ANTHROPIC_API_KEY is empty and every API-calling eval fails at SDK auth (Could not resolve authentication method). I reran each failing test on both the PR head and clean main with credentials scrubbed and got identical failures on both, across 57 retry attempts, 0 tokens, $0.00. The report shard fails separately because a fork's read-only token cannot addComment. Everything that does not need a secret passes: actionlint, check-freshness, build-image, windows-free-tests, windows-setup, and the new non-LLM unit tests. Full breakdown is in this comment on #2323.

    Getting genuinely green evals needs a trusted rerun from a base-repository branch (fork and parent share git objects, so git fetch origin pull/2323/head then pushing that to an upstream branch reuses the exact commits, no rework). I did not change the workflow in this PR: using pull_request_target to run untrusted fork code with secrets would be unsafe, and a fork-skip policy for paid evals is a repository-level decision that does not belong in a host-support PR.

    Happy to adjust scope, split it, or fold in anything from #396 that is worth preserving.

  10. andrey-esipov commented on Jul 25, 2026

    @andrey-esipov
    Contributor

    Two follow-ups on this thread, both relevant to anyone who tries to land Copilot support from a fork.

    1. Fork PRs cannot reach green on this repo's eval workflow, no matter the code. I chased #2323's red checks to the bottom, and the blocker is structural rather than anything in a contributor's branch. GitHub withholds repository secrets from a pull_request opened from a fork, so ANTHROPIC_API_KEY is empty and every API-calling eval dies at SDK auth. e2e-pty-plan-smoke matters most here: it does not use diff-based test selection (shouldRun = EVALS && EVALS_TIER === 'gate'), so it runs on every PR regardless of the diff and needs an authenticated claude. A one-line fork PR would fail it too. I confirmed unrelated fork PRs from different authors failing with byte-identical errors, and no currently open PR in the repo has green evals — the ones that look green never ran them.

    That is worth stating plainly on this issue, because four Copilot attempts have now come and gone (#396, #487, #1852, plus @rodneymhungu's reference branch), and "the CI is red" is an easy reason to skip past the next one without realizing no fork submission can clear that bar.

    2. Which outcome you get is decided by Docker cache state, not by your code. evals needs build-image, and the CI image tag is content-hashed over Dockerfile.ci / package.json / bun.lock. On a fork PR with the image already cached, build-image passes, the eval shards run, and everything fails on the missing key. With the image not cached, build-image fails its ghcr.io push, evals skips, and the PR looks clean. Identical code, opposite verdicts — #2264 merged in the second state, #2323 sits in the first.

    I opened #2345 to make that deterministic: gate build-image, evals, and report on the PR head being in the base repository, so fork PRs skip these jobs for a stated reason every time instead of by cache luck. Same-repo PRs, pushes, and workflow_dispatch keep full coverage, and it deliberately does not add skip-on-missing-key to the harness (that would weaken real runs and contradict the existing refusing to skip policy) and does not use pull_request_target. It is filed separately so #2323 carries no CI edits.

    Neither point changes what #2323 does. Getting real eval coverage on it just needs a maintainer to push the commits to a base-repo branch — fork and parent share git objects, so git fetch origin pull/2323/head and pushing that ref reuses the exact commits with no rework.

  11. capy-ai commented on Oct 3, 2026

    @capy-ai
    Contributor

    Fixed in v1.91.16.0 (#3014, ac20ef1): ./setup --host copilot installs gstack for GitHub Copilot CLI (~/.copilot/skills) at the experimental tier, selectively ported from #2323 with credit to @andrey-esipov, @ridermw and @lolisaigao1234. Full-tier certification needs a recorded real workflow run (see docs/ADDING_A_HOST.md).

    Thanks for the report! If it still happens on v1.91.16.0 or later, reply here and we'll reopen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions