Skip to content

feat(save): connect the session that had nothing to what it just saved - #85

Merged
tanglearncode merged 1 commit into
mainfrom
feat/save-connects-an-unconnected-session
Aug 9, 2026
Merged

tanglearncode merged 1 commit into
mainfrom
feat/save-connects-an-unconnected-session

Conversation

@tanglearncode

Copy link
Copy Markdown
Contributor

What changes

Saving a conversation now decides the connection, instead of always leaving it alone:

  • Nothing connected → the save connects the session to the context it just wrote, whether that was a create or a confirmed update. The output says so, and no /neatcontext:use on the thing you just wrote is needed.
  • Already connected → nothing moves. Save As under a new name still writes the new context, and the output states that this session stays on the one it was working in.
  • Updating the context you are already connected to behaves exactly as before.

Why

A save is the one command that makes a context out of the conversation in front of it, so it is the one place a connection can be inferred rather than asked for. A session with nothing connected has no grounding to lose and has just written the context that describes it.

The other half matters just as much: Save As is filing this work somewhere else, and moving the session onto that copy would re-ground a conversation the user is still having, without them asking for it.

How

One shared helper, connectAfterSave() in shared/core/selection.mjs, holds the rule; the packaged cores are synced from it so every host applies it identically. Each host's save path reports which of the two cases it took:

  • Claude Code, Copilot, Kimi, Codex CLIs — printSaveConnection(). On Claude and Codex it also re-runs the bridge-drift warning, the same exposure use has.
  • pi runtime — saveConnectionLines().

Docs that said the opposite are corrected: save.md for Claude Code and Copilot, SKILL.md for Kimi, Codex, and pi, and the save walkthrough in the root and Codex READMEs.

Behavior change worth knowing

After a first /neatcontext:save, a second nameless /neatcontext:save is now Save, not Save As: it previews a merged update to the context the session is now connected to, instead of creating a second one. save-target semantics are pinned by test.

Verification

  • npm run check — clean
  • node --test — 455/455 pass
  • npm run coverage — all 171 changed lines covered

New tests cover both halves of the rule (connect-when-empty, stay-put-when-connected, and update-the-connected-context) for Claude Code, Copilot, Kimi, Codex, and pi. The Copilot and Kimi save paths had no test coverage before this.

🤖 Generated with Claude Code

Saving is the one command that makes a context out of the conversation in
front of it, so it is the one place a connection can be inferred rather than
asked for. A session with nothing connected has no grounding to lose and has
just written the context that describes it, so the save connects it and says
so — no `use` on the thing you just wrote.

A session that already has a context keeps it, whatever the save wrote to.
Saving under another name is Save As: filing this work somewhere else must not
re-ground a conversation the user is still having.

The rule lives in one shared helper so every host applies it identically, and
each host reports which of the two cases it took. A second nameless save is
now Save rather than Save As, because the first one connected the session.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@tanglearncode
tanglearncode merged commit 2b3106f into main Aug 9, 2026
11 checks passed
@tanglearncode tanglearncode mentioned this pull request Aug 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant