# Inspect and Edit Context The model only ever sees a projection of your session: the ordered list of messages kli builds and sends on the next turn. The `/context` command shows you that projection and lets you change it. Edits are staged first and applied as a group, so you can review or discard them before they reach the model. This guide covers `inspect`, `stage`, `diff`, `commit`, and `revert`. ## View the current projection Run `/context inspect` to see what the model would receive right now: ``` /context inspect ``` The header reports three numbers: ``` Context epoch 4, 12 messages, 0 staged. ``` The **epoch** counts how many times you have committed edits to this context; it starts at 0 and increments by one per commit. The **message count** is the length of the projection. The **staged** count is how many edits are waiting to be applied. When edits are staged, `inspect` lists them under a `Staged:` block. Positions are zero-based; target a message by index for removal or replacement. ## Stage an edit `/context stage` takes one of three subcommands as its first word. Staging records the edit but does not change the projection yet. Add a message to the end of the projection: ``` /context stage append ``` The text becomes a user message appended after the current last message. Remove the message at a given index: ``` /context stage remove ``` Replace the message at a given index with new text: ``` /context stage replace ``` Each stage command confirms the running total, for example `Staged append-message patch (2 total).` Stage as many edits as you need; they accumulate in order. ## Review staged edits Before applying anything, see exactly what is pending: ``` /context diff ``` This lists every staged edit without committing. An append shows the text to be added, a remove shows the target index, and a replace shows the new text. With nothing staged, it reports `No pending context changes.` ## Apply the edits When the staged set is what you want, commit it: ``` /context commit ``` Commit applies all staged edits to the projection as a single group, clears the staging area, and bumps the epoch by one. It reports the count and the new epoch, for example `Committed 3 patches (epoch 5).` If nothing is staged, it reports `No staged patches to commit.` A commit is recorded in the session log, so the edited projection survives across saves and resumes. Removal and replacement match the message sitting at the given index when the commit rebuilds the projection. If no message sits at that index, the edit applies to nothing and the projection is unchanged, so use `/context inspect` first to read off the index you mean. ## Discard staged edits To throw away everything you have staged without applying it: ``` /context revert ``` This clears the staging area and reports how many edits it discarded. It does not touch already-committed changes; only the pending set is affected. With nothing staged, it reports `No staged patches to revert.` ## Capabilities these commands need Inspecting, staging, and committing each need a capability; `diff` is ungated and always runs. With the default settings the `capabilities` key is absent, so every subcommand is allowed. If you restrict tools through the `capabilities` array in `settings.json`, list the ones you want: | Subcommand | Capability | | --- | --- | | `inspect` | `context/read` | | `stage`, `revert` | `context/stage-edit` | | `commit` | `context/commit-edit` | See [Restrict Tool Capabilities](/kli/guides/restrict-what-kli-can-do) for how the `capabilities` array works, and [The Agent Loop](/kli/concepts/the-agent-loop) for where the projection sits in a turn.