Skip to content

fix: give the Pi runner a session identity, so continuity actually happens - #80

Merged
bborbe merged 1 commit into
masterfrom
fix/session-continuity
Sep 26, 2026
Merged

bborbe merged 1 commit into
masterfrom
fix/session-continuity

Conversation

@bborbe

@bborbe bborbe commented Sep 26, 2026

Copy link
Copy Markdown
Owner

The defect

PersistSession omitted --no-session and nothing else. From pi's own --help:

--print, -p          Non-interactive mode: process prompt and exit
--continue, -c       Continue previous session
--session-id <id>    Use exact project session ID, creating it if missing
--no-session         Don't save session (ephemeral)

--no-session governs whether pi writes the transcript. Reading it back is a different flag. So an agent configured for continuity saved every conversation and remembered none of them — observed live:

  • turn 1 → ACK
  • turn 2 → {"status":"failed","message":"No token was previously requested to be remembered"}

which is precisely what a fresh session says.

The fix

PiRunnerConfig.SessionID passes pi's --session-id. --session-id rather than --continue deliberately: it creates the session when it is missing, so a brand-new agent's first prompt behaves exactly like its thousandth — --continue would be resuming nothing on that first run.

Left empty for a task-routed agent, whose runs are unrelated tasks that must not be joined into one identity.

Why it got through

The plan that scoped the work said:

runs pi --print --mode json --no-session, so session storage in the PVC-mounted ~/.pi/agent/ is never written. The delta is dropping --no-session.

The first clause is true; the second does not follow. Writing a session and continuing one are different flags, and nothing exercised the difference until a second prompt was sent to the same pod. PersistSession was implemented, reviewed, and unit-tested on both sides without anyone asking whether the flag it removes is the flag that resumes.

Tests

9 of 9 specs in the pi package, up from 7 — two new: --session-id is passed when configured, and no --session-id is passed when it is not. make precommit PASS — go test -race all 10 packages, golangci-lint 0 issues, gosec clean, trivy 0 vulns / 0 secrets, osv clean.

…ppens

PersistSession only omitted --no-session, which governs whether pi writes
the transcript. Reading it back is a different flag — so an agent
configured for continuity saved every conversation and remembered none of
them: a two-prompt proof returned the first answer and then "No token was
previously requested to be remembered", which is what a fresh session says.

PiRunnerConfig.SessionID now passes pi's --session-id, creating the session
on first use and continuing it thereafter.

--session-id rather than --continue deliberately: it creates the session
when it is missing, so a brand-new agent's first prompt behaves exactly
like its thousandth, where --continue would be resuming nothing. Left empty
for a task-routed agent, whose runs are unrelated tasks that must not be
joined into one identity.
@bborbe
bborbe marked this pull request as ready for review September 26, 2026 22:11

@ben-s-pull-request-reviewer ben-s-pull-request-reviewer Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CHANGELOG has ## Unreleased with a fix: prefix — standard convention. All three concerns from the plan are addressed. No issues found.

Summary

The fix adds SessionID to PiRunnerConfig and passes --session-id to the pi CLI when set. The bug: PersistSession=true only omitted --no-session (writing control), but reading the session back requires --session-id. An agent with persistence but no session ID saved every conversation and remembered none.

Verification:

  • pi/pi-runner.go:108-110 — correctly appends --session-id when SessionID != "", complementing PersistSession
  • pi/pi-runner-config.go:31-48 — PersistSession docs correctly distinguish write vs read; SessionID docs correctly explain why --session-id (not --continue) and when to leave it empty
  • pi/pi-runner_test.go:100-116 — both cases tested: session ID present and absent

No issues found.


{
  "verdict": "approve",
  "summary": "Bugfix correctly adds the missing --session-id flag that makes session continuity work. PersistSession only controls writing the transcript; --session-id is the separate flag that allows reading it back. Two new specs cover both configured and unconfigured cases. Documentation clearly explains the relationship between the two flags.",
  "comments": [],
  "concerns_addressed": [
    {
      "concern": "correctness: PersistSession removed --no-session but that flag only controls writing; reading requires --session-id",
      "disposition": "addressed",
      "detail": "pi-runner.go:108-110 adds --session-id when SessionID != ''; pi-runner-config.go:31-48 documents the write/read distinction correctly"
    },
    {
      "concern": "correctness: New SessionID field documentation must correctly distinguish --no-session from --session-id",
      "disposition": "addressed",
      "detail": "pi-runner-config.go:31-48 explains PersistSession controls writing and SessionID controls reading; explains why --session-id (not --continue)"
    },
    {
      "concern": "tests: Two new specs added — verify both exercise buildCommand fully",
      "disposition": "addressed",
      "detail": "pi-runner_test.go:100-116 tests --session-id passed when configured and omitted when not, both via the buildCommand path using the shim"
    }
  ]
}

@bborbe
bborbe merged commit c1aecf6 into master Sep 26, 2026
5 checks passed
@bborbe
bborbe deleted the fix/session-continuity branch September 26, 2026 22:15
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