You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
Reacted by Mike, David Grant, David Gambo, @lex, Yi (Flora) Liu, xgolf-chris and Rai En
Reacted by Alex Yovev, samotoo, Dmitriy Van der Elst, Elio Struyf, salih-logo, Jinhong Chen, Aiden, Kingsley Mensah, arafter-flextrade, Ross Bender and 16 more
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.
Reacted by Alex Yovev, Aiden, Minseok Song, arafter-flextrade, Nurbakhyt, alanlv, David Grant and strattonn
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.
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.
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.
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.
Activity
ridermw commentedon Mar 25, 2026
I just pushed a smaller PR for this: #487 .
It takes the minimal-support path by using Copilot CLI's documented
.claude/skillscompatibility instead of adding a new Copilot-specific host/generator path, but it also includes Copilot in session discovery for/retro global.arkar16 commentedon Mar 28, 2026
Is this ready to implement and use? Thanks for making this a first-class option. Good to add more harnesses
maskaravivek commentedon Mar 30, 2026
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.
Thypari commentedon Apr 22, 2026
Any updates on this?
ganmuru commentedon Apr 29, 2026
Can someone look into this?
feat(copilot): install gstack skills via ridermw/gstack PR branch
rodneymhungu commentedon Jun 5, 2026
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 onbin/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: onehosts/copilot.tsconfig plus a small adapter, with./setup --host copilotcopyinggstack-<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.
time-attack commentedon Jul 15, 2026
@ridermw GitHub Copilot CLI support remains unresolved, and this issue is the primary place tracking that work.
dgrant commentedon Jul 22, 2026
Looks like #2323 was just created
andrey-esipov commentedon Jul 24, 2026
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
copilothost (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 (head0b41da9d), including a newtest/copilot-host.test.tsand updatedtest/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/DIRTYwith 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
reportare red, and all of them are fork-secret injection rather than code defects. GitHub does not pass repository secrets to apull_requestfrom a fork, soANTHROPIC_API_KEYis 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 cleanmainwith credentials scrubbed and got identical failures on both, across 57 retry attempts, 0 tokens, $0.00. Thereportshard fails separately because a fork's read-only token cannotaddComment. 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/headthen pushing that to an upstream branch reuses the exact commits, no rework). I did not change the workflow in this PR: usingpull_request_targetto 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.
andrey-esipov commentedon Jul 25, 2026
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_requestopened from a fork, soANTHROPIC_API_KEYis empty and every API-calling eval dies at SDK auth.e2e-pty-plan-smokematters 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 authenticatedclaude. 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.
evalsneedsbuild-image, and the CI image tag is content-hashed overDockerfile.ci/package.json/bun.lock. On a fork PR with the image already cached,build-imagepasses, the eval shards run, and everything fails on the missing key. With the image not cached,build-imagefails its ghcr.io push,evalsskips, 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, andreporton 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, andworkflow_dispatchkeep full coverage, and it deliberately does not add skip-on-missing-key to the harness (that would weaken real runs and contradict the existingrefusing to skippolicy) and does not usepull_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/headand pushing that ref reuses the exact commits with no rework.feat(setup): install registry, ./setup --status, staged activation, p…
v1.91.16.0 fix: safe installs and upgrades, skills start everywhere, …
capy-ai commentedon Oct 3, 2026
Fixed in v1.91.16.0 (#3014, ac20ef1):
./setup --host copilotinstalls 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.
v1.91.16.0 fix: safe installs and upgrades, skills start everywhere, …