Connect
Gemini CLI

Give Gemini CLI memory across sessions.

Add the Bilinc adapter to Gemini CLI's settings and it can recall what earlier sessions decided before it acts, then keep what each session settled, with where it came from and every earlier version.

Start free MCP clients guide MCP tools

Set it up.

Gemini CLI runs the Bilinc MCP adapter from the bilinc Python package, which reads the key bilinc login saved.

Install the package and sign in. One package gives you the Python SDK, the bilinc command and the MCP adapter. bilinc login opens your browser and saves the key on this machine.
Terminal
```
pip install -U bilinc
bilinc login
```
Add Bilinc to settings.json. Gemini CLI reads MCP servers from an mcpServers object in ~/.gemini/settings.json, or .gemini/settings.json for one project. bilinc mcp install prints this block with the absolute path of the Python that has Bilinc, and the adapter reads the key saved by bilinc login, so the config carries no key. On a machine without a saved key, add BILINC_API_KEY to the server's environment.
settings.json
```
{
  "mcpServers": {
    "bilinc": {
      "command": "python3",
      "args": ["-m", "bilinc.cloud_mcp"]
    }
  }
}
```
Check the connection. Start Gemini CLI and run /mcp. It lists your servers, whether each one is connected, and the tools it offers.

Where Gemini CLI keeps its MCP servers is described in Gemini CLI's MCP server guide.

What it changes for Gemini CLI.

A Gemini CLI session knows the directory it runs in and the conversation so far. The decisions behind the code, what was tried, what was ruled out, what is still open, are gone when the session ends. With Bilinc, Gemini CLI recalls them before it acts, and each result says where the memory came from and when it was last written or confirmed.

At the end of a task it commits what is worth keeping, with its source. revise replaces a memory deliberately rather than by accident, and every earlier version stays in the history.

Before risky work it can take a snapshot. diff then lists what changed since that checkpoint, and rollback restores it after a preview.

Things to ask.

Ask in your own words; the agent picks the Bilinc tool that fits.

“Recall what Bilinc has on this repo's release process before you change it.”
“Take a Bilinc snapshot before you start this migration.”
“Show what changed in Bilinc since the last snapshot.”
“Commit this task's outcome to Bilinc with the commands that verified it.”

The memory contract

Paste this into the instructions Gemini CLI reads, so it recalls before it acts and keeps only what is worth keeping.

Instructions for your agent

Before changing code, recall Bilinc memory for this repo.
Do not save secrets.
After the task, commit durable outcomes, verification commands, files changed, and caveats.

The tools it gets.

The tools of the local adapter, as the tool reference lists them.

The tools of the Bilinc MCP adapter
Tool	What it does
`commit_mem`	Writes durable memory with key, value, memory type, importance, and provenance metadata. Returns an entry version you can reuse for optimistic concurrency.
`recall`	Retrieves prior state with query, profile, and limit. Smart retrieval is the profile argument, not a separate tool.
`revise`	Deliberately replaces a memory you already have. Returns memory_not_found rather than creating, so a correction stays distinguishable from an accidental overwrite.
`forget`	Destructive. Removes a memory from active recall. A reason is required and is written to the audit trail; the deleted value is never returned.
`status`	Reports the authenticated workspace, plan, limits, supported capabilities, and recall profiles. Read-only and never billed.
`snapshot`	Creates or lists project checkpoints. Create is metered; list is free. Neither returns the checkpoint contents.
`diff`	Compares a checkpoint against another checkpoint or current state. Free, and values are redacted unless explicitly requested.
`history`	Read-only and free. Returns one memory’s recorded changes, newest first, with the value before and after each change. Values from before the memory was forgotten are never returned.
`list_memories`	Read-only and free. Returns a page of stored memories ordered by key, with prefix, type, and updated-time filters and a cursor for the next page.
`confirm`	Records that an existing memory is still accurate without resending its value. The value stays as stored, its last-updated time moves to now, and history shows a confirmation. One write operation.
`rollback`	Destructive in execute mode. Preview is free and returns a short-lived confirmation token; execute needs that token and permanently discards everything changed since the checkpoint.

The tool reference

Questions.

Where does the Gemini CLI config go?

In the mcpServers object of ~/.gemini/settings.json for every project, or .gemini/settings.json inside one project. bilinc mcp install prints the entry with the right Python path.

Does settings.json need an API key?

No. The adapter reads the key that bilinc login saved on your machine. A machine without a saved key needs BILINC_API_KEY in the server's environment.

How do I check that Bilinc is connected?

Run /mcp inside Gemini CLI. It shows each server, its connection status and its tools.

How do I undo a bad session?

Take a snapshot before risky work. diff compares it with the current state, and rollback restores it: a free preview first, then an explicit execute. Rollback works on checkpoints, not on single keys.

Is the memory shared with my other clients?

Yes. Every client connected to the same workspace shares its memory, whether it is Gemini CLI, Codex, Cursor or Claude.

Bilinc connects the same way everywhere.

One workspace, every client. The memory guides and comparisons answer the questions underneath.