Persistent Memory for
Google's Gemini CLI

Gemini CLI is Google's terminal-first AI coding tool — fast, capable, and completely amnesiac. Every session starts blank. This guide shows you how to wire Kronvex persistent memory into Gemini CLI via the REST API and GEMINI.md custom instructions, so your agent actually remembers what you've built.

Why Gemini CLI forgets everything

Gemini CLI (the open-source terminal client for Google's Gemini models) is built for interactive sessions. You launch it, work through a problem, and close the terminal. The next time you open it, it knows nothing about the previous session — no code decisions, no debugging history, no project context. You're back to pasting in background every time.

This is a fundamental design constraint, not a bug. Language models are stateless by nature; the context window only exists for the duration of a single API call. Gemini CLI has no built-in mechanism to persist and retrieve memory between sessions.

The workaround that most developers default to is pasting a wall of context text at the start of every session. This is tedious, error-prone, and scales poorly as projects grow. It also burns tokens on context that may not be relevant to the current task.

How Kronvex integrates with Gemini CLI

Gemini CLI does not support MCP servers directly (unlike Cursor or Cline), so the integration happens at a different layer: GEMINI.md custom instructions + REST API calls from the terminal.

The workflow has three parts:

• Before a session: a shell script queries the Kronvex /recall or /inject-context endpoint with today's task, retrieves relevant past memories, and writes them into a temporary context block that Gemini CLI picks up via GEMINI.md.
• During a session: you work normally with Gemini CLI. No change in UX.
• After a session: you (or a script) push a short summary of what was decided or discovered to the Kronvex /remember endpoint.

Kronvex stores memories as high-dimensional vectors (OpenAI text-embedding-3-small, 1536 dims) in a pgvector-enabled PostgreSQL database hosted in the EU. Recall uses cosine similarity with a compound confidence score that factors in recency and access frequency.

Step 1 — Get your Kronvex API key and Agent ID

Step 2 — Configure GEMINI.md for memory-aware sessions

Gemini CLI reads a GEMINI.md file from the current directory (or ~/.config/gemini/GEMINI.md for global instructions). This is where you tell Gemini how to behave — and where you'll inject recalled context at the start of each session.

Create or update GEMINI.md in your project root:

# Project: My Application
# Assistant configuration for Gemini CLI

## Role
You are a senior software engineer with deep knowledge of this codebase.
You have access to your memory from previous sessions below.

## Persistent Memory Context
# This block is updated automatically by kv-recall.sh before each session
# DO NOT EDIT BELOW THIS LINE MANUALLY
---BEGIN KRONVEX CONTEXT---

# (context injected here by pre-session script)

---END KRONVEX CONTEXT---

## Instructions
- Reference the memory context above when it is relevant to the current task
- Do not repeat context back to the user verbatim; use it to inform responses
- Ask clarifying questions before making architectural decisions

The section between the delimiters is what your recall script will rewrite before each session. Everything outside it is your static project instructions.

Step 3 — Store memories after each session

At the end of a productive session, push a summary to Kronvex using a simple curl call. The content can be a decision log, a bug root-cause, an architectural note — anything you'd want to remember next time.

curl -s -X POST "https://api.kronvex.io/api/v1/agents/${KRONVEX_AGENT_ID}/remember" \
  -H "X-API-Key: ${KRONVEX_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Switched from SQLite to PostgreSQL for the jobs table. Reason: concurrent writes from worker processes caused lock contention. Migration in db/migrations/0004_jobs_pg.sql.",
    "memory_type": "semantic",
    "session_id": "myproject"
  }'

The three memory types map naturally to engineering knowledge:

• semantic — facts and decisions ("we use PostgreSQL because…")
• episodic — things that happened ("fixed the auth bug on 2026-05-03")
• procedural — recurring patterns ("always run make test before PRs")

Step 4 — Recall context at session start

Use the /inject-context endpoint, which returns a pre-formatted string ready for injection into a system prompt:

curl -s -X POST "https://api.kronvex.io/api/v1/agents/${KRONVEX_AGENT_ID}/inject-context" \
  -H "X-API-Key: ${KRONVEX_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "message": "Implement background job processing with retry logic",
    "session_id": "myproject",
    "top_k": 6
  }' | jq -r '.context'

The response is a formatted block of the most semantically relevant memories — scored by the Kronvex confidence formula similarity × 0.6 + recency × 0.2 + frequency × 0.2. Only memories relevant to background jobs and retry logic will surface, not your entire history.

Automating the full loop with a shell script

The best developer experience is a script that does the recall automatically when you start a session and prompts you to remember at the end. Here is a minimal but complete implementation:

#!/usr/bin/env bash
# Gemini CLI session wrapper with Kronvex persistent memory

AGENT_ID="${KRONVEX_AGENT_ID}"
API_KEY="${KRONVEX_API_KEY}"
SESSION_ID="$(basename $(pwd))"  # use project folder as session scope
GEMINI_MD="./GEMINI.md"
DELIMITER_START="---BEGIN KRONVEX CONTEXT---"
DELIMITER_END="---END KRONVEX CONTEXT---"

# 1. Ask what we're working on today
echo "What are you working on today? (used for memory recall)"
read -r TASK

# 2. Recall relevant memories from Kronvex
echo "Recalling memories..."
CONTEXT=$(curl -s -X POST \
  "https://api.kronvex.io/api/v1/agents/${AGENT_ID}/inject-context" \
  -H "X-API-Key: ${API_KEY}" \
  -H "Content-Type: application/json" \
  -d "{\"message\": \"${TASK}\", \"session_id\": \"${SESSION_ID}\", \"top_k\": 8}" \
  | jq -r '.context // "No relevant memories found."')

# 3. Inject context into GEMINI.md between delimiters
if [[ -f "$GEMINI_MD" ]]; then
  BEFORE=$(awk "/^${DELIMITER_START}$/{exit} {print}" "$GEMINI_MD")
  AFTER=$(awk "found{print} /^${DELIMITER_END}$/{found=1}" "$GEMINI_MD")
  printf "%s\n%s\n%s\n%s\n%s\n" \
    "$BEFORE" "$DELIMITER_START" "$CONTEXT" "$DELIMITER_END" "$AFTER" \
    > "$GEMINI_MD"
fi

# 4. Launch Gemini CLI
gemini

# 5. After session — prompt to save a memory
echo ""
echo "Session ended. What should be remembered? (leave blank to skip)"
read -r MEMORY

if [[ -n "$MEMORY" ]]; then
  curl -s -X POST \
    "https://api.kronvex.io/api/v1/agents/${AGENT_ID}/remember" \
    -H "X-API-Key: ${API_KEY}" \
    -H "Content-Type: application/json" \
    -d "{\"content\": \"${MEMORY}\", \"memory_type\": \"semantic\", \"session_id\": \"${SESSION_ID}\"}" \
    > /dev/null
  echo "Memory saved."
fi

Run it instead of gemini directly: gemini-session. You get context-aware sessions with zero manual copy-pasting.

Real-world use cases

Long-running refactoring projects

You're migrating a legacy PHP application to TypeScript over several weeks. Each Gemini CLI session can start with the relevant architectural decisions from previous sessions — which modules have been migrated, which patterns emerged, which edge cases were discovered. Without memory, you'd repeat the same contextual briefing every day.

Multi-repository codebases

Use a shared Kronvex agent across multiple repos with different session_id values per project. When you switch from the frontend repo to the API repo, the recalled context is automatically scoped to that project. Cross-project memories (shared auth decisions, API contract changes) use a common session ID.

Team knowledge base

Multiple engineers on the same team sharing one Kronvex API key and agent build a living knowledge base of project decisions. When a new team member uses Gemini CLI on the project, they immediately get context from months of engineering decisions without reading through hundreds of PRs and Slack threads.

Tips and best practices

Keep memories atomic and specific

A memory that says "we made some changes to the database" is useless. A memory that says "changed users.email to a unique index in migration 0012 because duplicate emails caused auth failures on social login" is highly retrievable and actionable. Treat each memory as an immutable fact or decision with enough context to stand alone.

Use session IDs consistently

The script above uses the current directory name as session ID. For projects with submodules or microservices, you may want a more explicit naming convention: myapp-frontend, myapp-api, myapp-infra. Consistent session IDs ensure recall stays scoped and doesn't mix context from unrelated projects.

Set TTL on ephemeral context

Not every memory deserves to live forever. Add "ttl_days": 30 to the remember API call for temporary scaffolding decisions, debugging notes, or spike work. Long-term architectural decisions should have no TTL. This keeps your memory store clean and recall scores high over time.

• EU data residency: all Kronvex memories are stored in Frankfurt — fully GDPR-compliant for European teams
• Semantic search, not keyword: recall works by meaning, not exact match — "database performance issue" will retrieve a memory about "slow query on the orders table"
• API latency: Kronvex recall typically completes in 30–60ms — negligible in a session startup script
• Free plan: 500 memories and 3 agents, no credit card required — enough to run the full setup for a small project