| 1 | # siGit Code vs GitHub Copilot CLI: parity and the three biggest wins |
| 2 | |
| 3 | Status: draft v1 (2026-07-04). Owner: product/eng. Audience: internal (private repo). |
| 4 | Scope: **siGit Code**, the Rust CLI / ACP agent. Companion to |
| 5 | [sigit-code-parity-roadmap.md](sigit-code-parity-roadmap.md), which compares |
| 6 | against Claude Code; this document compares against **GitHub Copilot CLI** and |
| 7 | specifies the next three features. Each spec is implementable on its own branch |
| 8 | off `development` in the `sigit` repo, independent of the others. |
| 9 | |
| 10 | Source basis: GitHub's Copilot CLI docs and changelog as of July 2026. Copilot |
| 11 | CLI went GA in February 2026 and shipped a redesigned terminal interface in June |
| 12 | 2026, so this comparison is against a fast-moving GA product, not a preview. |
| 13 | |
| 14 | --- |
| 15 | |
| 16 | ## 1. Where we stand |
| 17 | |
| 18 | Copilot CLI is the closest competitor in spirit: a terminal agent that also |
| 19 | speaks ACP and also ships skills, plan mode, MCP, and custom instructions. The |
| 20 | open PRs from the Claude Code roadmap (sigit #22 background commands, #23 |
| 21 | subagent tool, #24 durable sessions and compaction) already close three gaps |
| 22 | that used to be Copilot advantages. What remains: |
| 23 | |
| 24 | | Capability | Copilot CLI | siGit Code today | |
| 25 | |---|---|---| |
| 26 | | Plan mode | yes (Shift+Tab, agent picker) | yes (/plan) | |
| 27 | | Skills / custom instructions | yes | yes (Agent Skills + AGENTS.md/CLAUDE.md) | |
| 28 | | MCP | built-in GitHub server + custom, stdio | official sigit.si server + custom, HTTP only | |
| 29 | | ACP | yes | yes (it is our native protocol) | |
| 30 | | On-device inference | no (BYO endpoint only) | yes, in-process via onde | |
| 31 | | Model picker | Anthropic/OpenAI/Google + reasoning effort | local models + cloud tiers + BYO | |
| 32 | | Context compaction | auto at 95% + /compact + /context | in PR #24 | |
| 33 | | Session resume | yes, across machines + /remote | in PR #24 (local only) | |
| 34 | | Background commands | not first-class | in PR #22 | |
| 35 | | Subagents / custom agents | yes, with automatic delegation | task tool in PR #23 | |
| 36 | | Permission rules | allow/deny patterns like `shell(git push)` | mode + per-tool only | |
| 37 | | Headless / programmatic mode | yes (`copilot -p`, approval flags) | no | |
| 38 | | Git-host workflows in the terminal | Issues/PRs/Actions tabs, create/review/merge | none | |
| 39 | | Sandboxing | local `/sandbox` + cloud `--cloud` | no | |
| 40 | | Hooks | yes | no | |
| 41 | | Persistent memory | Copilot Memory | `remember` tool, no recall layer | |
| 42 | |
| 43 | siGit's edge is real: in-process on-device inference, and ACP as the native |
| 44 | protocol rather than an add-on. The three specs below are where Copilot CLI is |
| 45 | ahead in ways that matter most, ordered smallest to largest. |
| 46 | |
| 47 | --- |
| 48 | |
| 49 | ## 2. Spec: permission rule patterns |
| 50 | |
| 51 | **Branch:** `feature/permission-rules` · **Touches:** `src/permissions.rs`, `src/settings.rs` |
| 52 | |
| 53 | ### Problem |
| 54 | |
| 55 | The permission system (merged PR #20) knows three modes and per-tool overrides. |
| 56 | That makes autonomy all-or-nothing per tool: `run_command = "allow"` waves |
| 57 | through `rm -rf` along with `cargo test`. Copilot CLI's `--allow-tool |
| 58 | "shell(git push)"` granularity is what makes long unattended runs safe, and our |
| 59 | own longer-running sessions (PR #24 raises the round cap) make this urgent. |
| 60 | |
| 61 | ### Design |
| 62 | |
| 63 | - `[permissions.rules]` in settings.toml: ordered lists `allow = [...]` and |
| 64 | `deny = [...]` of rule strings. A rule is `tool_name` or |
| 65 | `tool_name(argument_prefix)`, e.g. `run_command(git status)`, |
| 66 | `run_command(cargo *)`, `edit_file(src/*)`. Matching for `run_command` is |
| 67 | against the command string; for file tools against the path argument. `*` |
| 68 | is a glob-style wildcard (reuse the `glob_to_regex` helper in tools.rs). |
| 69 | - Evaluation order inside `decision_for`, after plan mode and session grants: |
| 70 | deny rules, then allow rules, then the existing per-tool override, then the |
| 71 | default mode. First match wins; deny always beats allow. |
| 72 | - Session grants gain the same granularity: the approval prompt's "always |
| 73 | allow" records `tool(prefix)` for `run_command` (the first token pair of the |
| 74 | command, e.g. `git push`) instead of the bare tool name, so one approval |
| 75 | covers the command family without opening the whole shell. |
| 76 | - `/permissions` prints the active rule lists. |
| 77 | |
| 78 | ### Acceptance |
| 79 | |
| 80 | - With `deny = ["run_command(git push*)"]` and `allow = ["run_command(git *)"]`, |
| 81 | `git status` runs, `git push` is denied, everything else asks. |
| 82 | - Rules survive settings reload; unit tests cover ordering, wildcard matching, |
| 83 | and the deny-beats-allow invariant. |
| 84 | |
| 85 | --- |
| 86 | |
| 87 | ## 3. Spec: headless programmatic mode |
| 88 | |
| 89 | **Branch:** `feature/headless-mode` · **Touches:** `src/main.rs` (arg parsing, new run mode) |
| 90 | |
| 91 | ### Problem |
| 92 | |
| 93 | Copilot CLI's `copilot -p "prompt"` runs one task and exits, which is what CI, |
| 94 | scripts, and cron want. siGit has no equivalent: ACP needs a client and the TUI |
| 95 | needs a TTY. Our own [Cloud Agent plan](sigit-code-cloud-agent-plan.md) needs |
| 96 | exactly this entry point for its sandbox runner, so this spec is on the Cloud |
| 97 | Agent critical path. |
| 98 | |
| 99 | ### Design |
| 100 | |
| 101 | - `sigit -p "<prompt>"` (long form `--prompt`): resolve the backend exactly like |
| 102 | the ACP path (provider override, cloud when signed in, on-device), run one |
| 103 | agent turn loop against the prompt with the full toolset, stream assistant |
| 104 | text to stdout, exit 0 on completion. Logs stay on stderr. `--quiet` prints |
| 105 | only the final message. |
| 106 | - Permissions in headless mode: default deny for anything that would ask (there |
| 107 | is nobody to ask). `--allow-tool <rule>` / `--deny-tool <rule>` flags feed the |
| 108 | rule engine from spec 2 for the run; `SIGIT_PERMISSIONS=allow` keeps working |
| 109 | as the blunt instrument. If spec 2 lands second, the flags start as bare tool |
| 110 | names and gain patterns when it lands. |
| 111 | - `--cwd <dir>` sets the working directory; instruction files load from there |
| 112 | like every other entry point. |
| 113 | - Exit codes: 0 success, 1 inference or tool-loop error, 2 bad invocation. |
| 114 | |
| 115 | ### Acceptance |
| 116 | |
| 117 | - `sigit -p "list the rust files here and count the tests" --allow-tool |
| 118 | run_command` works in CI (no TTY) against a configured provider and exits 0. |
| 119 | - A prompt that needs a denied tool finishes with the denial surfaced in the |
| 120 | output rather than hanging. |
| 121 | - Integration test drives the built binary with `-p` against the scripted |
| 122 | OpenAI-compatible endpoint harness from `tests/acp_permissions.rs`. |
| 123 | |
| 124 | --- |
| 125 | |
| 126 | ## 4. Spec: git-host workflows in the terminal |
| 127 | |
| 128 | **Branch:** `feature/githost-tools` · **Touches:** `src/tools.rs`, official MCP server (sigit-si side) |
| 129 | |
| 130 | ### Problem |
| 131 | |
| 132 | Copilot CLI ships a built-in GitHub MCP server plus Issues and Pull requests |
| 133 | tabs: the agent reads issues, opens PRs, reviews and merges without leaving the |
| 134 | terminal. siGit Code has the official sigit.si MCP server baked in but exposes |
| 135 | no repository workflows through it, and sigit.si is literally our own git host. |
| 136 | Our agent should be the best terminal client sigit.si has. |
| 137 | |
| 138 | ### Design |
| 139 | |
| 140 | - sigit-si side: extend the official MCP server (`/api/v1/mcp`) with repo |
| 141 | workflow tools for the authenticated user: `list_issues`, `get_issue`, |
| 142 | `create_issue`, `list_pull_requests`, `get_pull_request` (diff included), |
| 143 | `create_pull_request`, `comment_on_pull_request`. Repo defaults to the origin |
| 144 | remote of the session cwd when it points at sigit.si; the tools take an |
| 145 | explicit `repo` argument otherwise. |
| 146 | - siGit Code side: nothing structural, the MCP plumbing already namespaces and |
| 147 | routes these (`mcp__sigit__*`); the work is prompt-level. Teach the system |
| 148 | prompt that issue and PR workflows on sigit.si repos go through those tools, |
| 149 | and classify the read-only ones (`list_*`, `get_*`) as read-only in |
| 150 | `permissions.rs` so browsing issues never prompts. |
| 151 | - GitHub repos: not in scope here. The Git-host adapter direction from the |
| 152 | Cloud Agent plan covers it later; users can already add GitHub's own MCP |
| 153 | server in mcp.toml today, which becomes the documented recipe. |
| 154 | |
| 155 | ### Acceptance |
| 156 | |
| 157 | - In a repo cloned from sigit.si, "what open issues mention auth, and open a PR |
| 158 | for this branch that references the right one" works end to end with only |
| 159 | the create/comment steps prompting for permission. |
| 160 | - Server-side request specs cover the new MCP tools; client-side unit tests |
| 161 | cover the read-only classification. |
| 162 | |
| 163 | --- |
| 164 | |
| 165 | ## 5. Sequencing |
| 166 | |
| 167 | Permission rules first (smallest, and headless mode wants its flags), then |
| 168 | headless mode (Cloud Agent critical path), then git-host workflows (spans both |
| 169 | repos). Fast follows from the table: stdio MCP transport, hooks, local |
| 170 | sandboxing, and a recall layer over `remember`. |