The CLI

Session capture and learning

What your team learns while working with its agents is knowledge too. The sidecar captures sessions as your organization allows, redacts them on your machine, and uses your own assistant to keep the team's knowledge base current.

What is captured

While you work in a folder connected to a project, the sidecar captures your sessions and sends them to that project's server as you go: at the end of each turn it uploads what the turn added, so your prompts appear on the server's Prompts page right away. A session closes when it ends, or after 30 idle minutes, and the server then extracts memory candidates from it.

Who decides

Your organization's admins set the capture policy on the server (Settings → Session capture), and you can opt out:

Nothing is captured until the sidecar has read the policy from the server, and the server enforces it again when a session arrives — whatever a sidecar sends. knwlge statusCopy to clipboard shows the mode in effect for you.

Redaction

Secrets are removed and personal data masked on your machine before anything is uploaded, and again on the server. Only what survives both reaches the database, and in full mode that is what an admin can read.

Turning it off

• For yourself, everywhere: open your server's console, go to My memory → Session capture, and opt out. It holds on every machine and every sidecar, and the server refuses your sessions from then on.
• For one sidecar: start it with KNWLGE_SESSION_CAPTURE_ENABLED=false in the foreground. The background service does not read your shell's environment.
• For the organization: an admin sets the policy to off.

Opting out also stops the learning nudge and the upkeep for your sessions, which only work on what capture recorded.

The learning nudge

At the end of a turn the sidecar looks up, in the project's catalog, what the assistant just worked with — the files it read, edited or searched, and the classes, tables and routes the prompt and answer named. When some of those are described only by what the indexer read from the code, or their description went stale, it asks the assistant once to save what it learned with knowledge.record. Each entry keeps one description that grows with every session, reviewed by an admin like any other.

• At most once a turn, three entries a request, each entry once a session — and never in the continuation it causes.
• The lookup sends repository-relative file paths and names only, never the text of your prompt or the answer.
• It follows the capture policy, and KNWLGE_LEARNING_NUDGE=off turns it off for a sidecar started with it.

Keeping the knowledge base

The team's documents and memories are kept by your own assistant, not by a model on the server. When a session closes, and at checkpoints while it is open, the sidecar runs the client you worked with a second time without a window — Claude Code (claude -p) or Codex (codex exec) — with a short record of what the session did. It updates the documents for the parts of the project you worked on, removes what the session showed is stale, and saves the rules and decisions you stated as memories.

• What it may do: only Knwlge's tools and reading code. It never edits code or runs commands, and its own session is never briefed, captured or nudged. Its changes are in each document's history as background.
• Bounded: one run at a time, ten minutes at most, 20 runs per project per day by default.
• Which model: the client's small model — Claude Code's haiku; Codex runs the model its own configuration names.
• What it costs: each run's tokens are counted as upkeep, in the control panel and in the usage Knwlge Global sees; the content stays on your Enterprise Server.
• The log: ~/.team-context-gateway/upkeep/<day>.jsonl, one line per run — project, client, model, tokens, outcome and, when it did not run, why. Never content.
• It runs only for sessions captured in full; KNWLGE_UPKEEP=off turns it off for a sidecar started with it.