@setoelkahfi / homebrew-tap
Code Commits Pulls CI/CD 205
main
main
md 8.18 KB
View source Raw

siGit Code vs GitHub Copilot CLI: parity and the three biggest wins

Status: draft v1 (2026-07-04). Owner: product/eng. Audience: internal (private repo). Scope: siGit Code, the Rust CLI / ACP agent. Companion to sigit-code-parity-roadmap.md, which compares against Claude Code; this document compares against GitHub Copilot CLI and specifies the next three features. Each spec is implementable on its own branch off development in the sigit repo, independent of the others.

Source basis: GitHub's Copilot CLI docs and changelog as of July 2026. Copilot CLI went GA in February 2026 and shipped a redesigned terminal interface in June 2026, so this comparison is against a fast-moving GA product, not a preview.

1. Where we stand

Copilot CLI is the closest competitor in spirit: a terminal agent that also speaks ACP and also ships skills, plan mode, MCP, and custom instructions. The open PRs from the Claude Code roadmap (sigit #22 background commands, #23 subagent tool, #24 durable sessions and compaction) already close three gaps that used to be Copilot advantages. What remains:

Capability Copilot CLI siGit Code today
Plan mode yes (Shift+Tab, agent picker) yes (/plan)
Skills / custom instructions yes yes (Agent Skills + AGENTS.md/CLAUDE.md)
MCP built-in GitHub server + custom, stdio official sigit.si server + custom, HTTP only
ACP yes yes (it is our native protocol)
On-device inference no (BYO endpoint only) yes, in-process via onde
Model picker Anthropic/OpenAI/Google + reasoning effort local models + cloud tiers + BYO
Context compaction auto at 95% + /compact + /context in PR #24
Session resume yes, across machines + /remote in PR #24 (local only)
Background commands not first-class in PR #22
Subagents / custom agents yes, with automatic delegation task tool in PR #23
Permission rules allow/deny patterns like shell(git push) mode + per-tool only
Headless / programmatic mode yes (copilot -p, approval flags) no
Git-host workflows in the terminal Issues/PRs/Actions tabs, create/review/merge none
Sandboxing local /sandbox + cloud --cloud no
Hooks yes no
Persistent memory Copilot Memory remember tool, no recall layer

siGit's edge is real: in-process on-device inference, and ACP as the native protocol rather than an add-on. The three specs below are where Copilot CLI is ahead in ways that matter most, ordered smallest to largest.

2. Spec: permission rule patterns

Branch: feature/permission-rules · Touches: src/permissions.rs, src/settings.rs

Problem

The permission system (merged PR #20) knows three modes and per-tool overrides. That makes autonomy all-or-nothing per tool: run_command = "allow" waves through rm -rf along with cargo test. Copilot CLI's --allow-tool "shell(git push)" granularity is what makes long unattended runs safe, and our own longer-running sessions (PR #24 raises the round cap) make this urgent.

Design

  • [permissions.rules] in settings.toml: ordered lists allow = [...] and deny = [...] of rule strings. A rule is tool_name or tool_name(argument_prefix), e.g. run_command(git status), run_command(cargo *), edit_file(src/*). Matching for run_command is against the command string; for file tools against the path argument. * is a glob-style wildcard (reuse the glob_to_regex helper in tools.rs).
  • Evaluation order inside decision_for, after plan mode and session grants: deny rules, then allow rules, then the existing per-tool override, then the default mode. First match wins; deny always beats allow.
  • Session grants gain the same granularity: the approval prompt's "always allow" records tool(prefix) for run_command (the first token pair of the command, e.g. git push) instead of the bare tool name, so one approval covers the command family without opening the whole shell.
  • /permissions prints the active rule lists.

Acceptance

  • With deny = ["run_command(git push*)"] and allow = ["run_command(git *)"], git status runs, git push is denied, everything else asks.
  • Rules survive settings reload; unit tests cover ordering, wildcard matching, and the deny-beats-allow invariant.

3. Spec: headless programmatic mode

Branch: feature/headless-mode · Touches: src/main.rs (arg parsing, new run mode)

Problem

Copilot CLI's copilot -p "prompt" runs one task and exits, which is what CI, scripts, and cron want. siGit has no equivalent: ACP needs a client and the TUI needs a TTY. Our own Cloud Agent plan needs exactly this entry point for its sandbox runner, so this spec is on the Cloud Agent critical path.

Design

  • sigit -p "<prompt>" (long form --prompt): resolve the backend exactly like the ACP path (provider override, cloud when signed in, on-device), run one agent turn loop against the prompt with the full toolset, stream assistant text to stdout, exit 0 on completion. Logs stay on stderr. --quiet prints only the final message.
  • Permissions in headless mode: default deny for anything that would ask (there is nobody to ask). --allow-tool <rule> / --deny-tool <rule> flags feed the rule engine from spec 2 for the run; SIGIT_PERMISSIONS=allow keeps working as the blunt instrument. If spec 2 lands second, the flags start as bare tool names and gain patterns when it lands.
  • --cwd <dir> sets the working directory; instruction files load from there like every other entry point.
  • Exit codes: 0 success, 1 inference or tool-loop error, 2 bad invocation.

Acceptance

  • sigit -p "list the rust files here and count the tests" --allow-tool run_command works in CI (no TTY) against a configured provider and exits 0.
  • A prompt that needs a denied tool finishes with the denial surfaced in the output rather than hanging.
  • Integration test drives the built binary with -p against the scripted OpenAI-compatible endpoint harness from tests/acp_permissions.rs.

4. Spec: git-host workflows in the terminal

Branch: feature/githost-tools · Touches: src/tools.rs, official MCP server (sigit-si side)

Problem

Copilot CLI ships a built-in GitHub MCP server plus Issues and Pull requests tabs: the agent reads issues, opens PRs, reviews and merges without leaving the terminal. siGit Code has the official sigit.si MCP server baked in but exposes no repository workflows through it, and sigit.si is literally our own git host. Our agent should be the best terminal client sigit.si has.

Design

  • sigit-si side: extend the official MCP server (/api/v1/mcp) with repo workflow tools for the authenticated user: list_issues, get_issue, create_issue, list_pull_requests, get_pull_request (diff included), create_pull_request, comment_on_pull_request. Repo defaults to the origin remote of the session cwd when it points at sigit.si; the tools take an explicit repo argument otherwise.
  • siGit Code side: nothing structural, the MCP plumbing already namespaces and routes these (mcp__sigit__*); the work is prompt-level. Teach the system prompt that issue and PR workflows on sigit.si repos go through those tools, and classify the read-only ones (list_*, get_*) as read-only in permissions.rs so browsing issues never prompts.
  • GitHub repos: not in scope here. The Git-host adapter direction from the Cloud Agent plan covers it later; users can already add GitHub's own MCP server in mcp.toml today, which becomes the documented recipe.

Acceptance

  • In a repo cloned from sigit.si, "what open issues mention auth, and open a PR for this branch that references the right one" works end to end with only the create/comment steps prompting for permission.
  • Server-side request specs cover the new MCP tools; client-side unit tests cover the read-only classification.

5. Sequencing

Permission rules first (smallest, and headless mode wants its flags), then headless mode (Cloud Agent critical path), then git-host workflows (spans both repos). Fast follows from the table: stdio MCP transport, hooks, local sandboxing, and a recall layer over remember.