Say what a Cline session does not bring with it from the host

Cline needs nothing on the host - no install, no login, no config, and
install.sh registers nothing for it because it hosts no guards. That is worth
stating, because it is the opposite of Claude Code, where an operator's
CLAUDE.md, settings, hooks, skills and plugins all come with them.

The same fact from the other side is the part that could disappoint someone:
none of their own Cline setup comes with them either. No rules, no MCP servers,
no plugins. A sandboxed Cline session starts from dejima's configuration and
dejima's briefing and nothing else.

The table separates two absences that have nothing to do with each other.
Session state and credentials are deliberate and permanent: one sessions.db
indexes every project Cline has run, and the real credential must not enter the
container. Rules, MCP servers and plugins are simply not built yet. Calling all
five "by design" would have been a tidier sentence and a false one.

And it says the expansion is a decision rather than a construction:
harness_config_dirs and harness_staged_config already exist and are what Claude
Code uses. Cline's plugin declares none of it. What is missing is a judgement
about which directories are safe to carry and at what mode.

One exception noted in both places, because it is easy to trip over: with
base_url unset, Cline reaches Anthropic through dejima's credential proxy, and
that proxy reads ~/.claude/.credentials.json. So that path does need a signed-in
Claude Code on the host - though still not a Cline.

docs/configuration.md

@@ -339,7 +339,46 @@ you don't have one.
 
 ### Cline
 
-Almost nothing carries over, and that is the design rather than a gap.
+**Nothing from your host Cline setup carries over, and Cline does not need to be
+installed on the host at all.** The image installs it; dejima writes its
+configuration; no host login, no host config, and `install.sh` registers nothing
+for it because it hosts no guards. That is the opposite of Claude Code above,
+where your `CLAUDE.md`, settings, hooks, skills and plugins all come with you.
+
+One exception, and it is Claude Code's rather than Cline's: with `base_url`
+unset, Cline reaches Anthropic through dejima's credential proxy, and that proxy
+reads `~/.claude/.credentials.json`. So that path needs a signed-in Claude Code
+on the host - though still not a Cline. Pointed at a model you serve yourself,
+nothing on the host is involved at all.
+
+#### What does not carry over, and why the reasons differ
+
+Two of these are deliberate and are not going to change. The rest is simply not
+built yet, and conflating them would overstate the design:
+
+| | carried? | why |
+| --- | --- | --- |
+| Session history and state | no, by design | one `sessions.db` indexes every project Cline has ever run; see below |
+| Provider credentials | no, by design | dejima writes a placeholder; the real credential never enters the container |
+| Rules (`~/Documents/Cline/Rules`, `~/.agents/AGENTS.md`) | **no, not yet built** | dejima writes its briefing into the first of these and carries nothing of yours |
+| MCP servers | **no, not yet built** | |
+| Plugins, skills, tasks | **no, not yet built** | |
+
+So a Cline session starts from dejima's configuration and dejima's briefing and
+nothing else. If you have written rules for Cline on your host, a sandboxed
+session will not see them; if you rely on an MCP server, it will not be there.
+
+**We expect to expand this.** The mechanism already exists and is what Claude
+Code uses - a harness declares which of its config directories carry over and at
+what mode, through `harness_config_dirs`, plus `harness_staged_config` for files
+that should arrive as read-only copies rather than mounts. Cline's plugin simply
+declares none of it today. Adding rules and MCP settings is a matter of deciding
+which directories are safe to carry and at what mode, not of building anything
+new. See "Config parity" in [development.md](development.md).
+
+Until then, treat a Cline sandbox as a fresh install with a briefing.
+
+#### Why the state directory is dejima's
 
 Cline keeps one `sessions.db` indexing every session it has ever run, with
 the project a session belonged to as a field inside the record rather than a

docs/providers.md

@@ -434,7 +434,11 @@ to its own hosted endpoint, which presents as a connection failure to a host
 nobody configured. The first real session turned up a second, in a component
 Cline does not own at all - the conversation shipper passed its payload as a
 command-line argument, which Cline's larger tool results overflow. It hosts no
-guards, so every launch names what is not in force.
+guards, so every launch names what is not in force, and it carries none of an
+operator's own Cline configuration into a session - no rules, no MCP servers,
+no plugins. That last one is not a design decision the way its state handling
+is; it is simply not built yet, and
+[configuration.md](configuration.md#cline) says which is which.
 
 Neither of those was a bad integration. That is the normal rate of discovery
 for something this new, and it is the reason to expect more.