Copilotcross-toolv0.3.17

GitHub Copilot CLI now supports Iranti shared memory

As of v0.3.17, iranti copilot-setup wires GitHub Copilot CLI into the same shared project memory as Claude Code and Codex. Copilot reads what the other tools wrote. You stop re-briefing every time you switch.

The same problem, a larger audience

GitHub Copilot CLI is one of the most widely used AI coding tools. It has deep IDE integration, GitHub-native context, and a large installed base — especially among developers who work primarily inside GitHub's ecosystem.

It has the same memory problem as every other AI coding tool: each session starts blank. Copilot has no memory of the architectural decisions you made last week, the constraint you discovered yesterday, or the task you left half-finished this morning. If you use Copilot alongside Claude Code or Codex — which a large number of developers do — there's no shared layer between them. Every tool switch is a full context reset.

v0.3.17 adds Copilot CLI to Iranti's supported integrations, alongside Claude Code, Codex CLI, and Cursor. One command from your project root wires it in.

How it works

Run iranti copilot-setup from your project root. It does three things:

1. Writes the MCP config

Adds Iranti as an MCP server in .vscode/mcp.json, which Copilot CLI picks up automatically. Iranti's tools — iranti_handshake, iranti_attend, iranti_write, and the rest — become available in every Copilot session.

2. Writes the protocol instructions

Generates .github/copilot-instructions.md with the Iranti protocol embedded. Copilot injects this file's contents into every session automatically — so the handshake and memory protocol runs at session start without any manual intervention.

3. Writes the hook scaffolding

Creates .github/hooks/hooks.json and the per-turn reminder script as forward-compatible placeholders. Copilot CLI's hook system is not yet as mature as Claude Code's — the static instructions file is the effective mechanism today — but the hook files are in place and will activate when Copilot's hook support matures.

After setup, Copilot calls iranti_handshake at the start of each session, reads the working memory brief, and picks up where the last session left off — regardless of which tool wrote that memory.

Setting it up

From your project root:

# Install Iranti globally (if you haven't already)
npm install -g iranti
# Wire up Copilot CLI
iranti copilot-setup

If you're also using Claude Code or Codex on the same project, run their setup commands too:

iranti claude-setup
iranti codex-setup

All three tools now share the same memory store. What Claude Code figures out in a session is available to Copilot in the next one, and vice versa.

The honest tradeoffs

Copilot's integration is real and works in practice, but it's worth being clear about where it stands relative to the other integrations:

Claude Code

The deepest integration. Native SessionStart and UserPromptSubmit hooks trigger memory injection automatically on every turn. The most reliable protocol compliance.

Codex CLI

Full hook support via ~/.codex/hooks.json. SessionStart and UserPromptSubmit hooks both fire, so session start and per-turn injection work natively.

GitHub Copilot CLI

Integration via static instructions injection (.github/copilot-instructions.md). Copilot reads these instructions at session start, so the handshake fires correctly. Per-turn hooks are scaffolded but Copilot's hook system is less mature — the instructions file is the primary enforcement mechanism today.

Cursor

Integration via MCP config and .cursor/rules. Works, but Cursor is the least tested of the four integrations.

What this means in practice

If you use GitHub Copilot CLI as your primary tool and occasionally drop into Claude Code for a complex architectural session, you no longer lose that context when you come back. Claude writes the decisions to Iranti. Copilot reads them at session start. You skip the re-briefing entirely.

If you use all three tools depending on the task — Claude Code for long exploratory sessions, Codex for focused implementation, Copilot for quick edits — they now all share a common understanding of your project. One memory store. Every tool reads from it. Every tool writes to it.

The goal is that the tool you pick for a given task shouldn't determine how much context it has. It should just know.

Get started

Iranti is open source (AGPL-3.0) and free to self-host. Requires Postgres with pgvector.

Comments

Loading...

0/2000