Add durable coding-agent session runtimes with locking, protocol projection, and JSONL persistence. Remove the obsolete legacy server implementation and dependency cycle.
* fix(coding-agent): resume after context-limited length stops
Treat length stops as context overflow when prompt usage is within 1% of
Pi's configured context window. Include cache-write tokens in that usage
and allow non-zero output because OpenAI may emit reasoning tokens before
returning an incomplete response.
After compaction, remove any retryable error or truncated-length assistant
message restored from persisted session history so the interrupted agent
turn can continue.
This is specifically for handling this case for openai models:
https://developers.openai.com/api/docs/guides/reasoning
> If the generated tokens reach the context window limit or the max_output_tokens value you’ve set, you’ll receive a response with a status of incomplete and incomplete_details with reason set to max_output_tokens. This might occur before any visible output tokens are produced, meaning you could incur costs for input and reasoning tokens without receiving a visible response.
This detection currently assumes the reported prompt usage is within 1% of
the context window configured in Pi. Its reliability therefore depends on
Pi's model contextWindow metadata matching the provider's effective limit.
Maybe we should consider treating OpenAI incomplete responses as requiring compaction
regardless of the local context-window estimate?
fixes#7020
* fix(coding-agent): recover truncated responses after compaction
Classify length stops by comparing provider-reported output usage with the model's intended output limit. Compact and retry once when generation ends below that limit, avoiding unreliable context-window estimates while preserving genuine max-output stops.
Normalize OpenAI Responses incomplete reasons so only max_output_tokens is treated as a length stop. Preserve qualified provider reasons for diagnostics, surface other reasons as errors, and use neutral truncation wording in the TUI.
* fix(coding-agent): preserve agent events during compaction
Manual compaction already waits for the active agent run to settle, and summary generation does not emit Agent events. Keep the agent subscription connected so unexpected concurrent events are not dropped, and remove the obsolete reconnect helper.
closes#7253
Images produced by tools (extensions, MCP bridges, screenshot tools) went into
session history at full resolution because processImage was only wired to the
read tool and @file CLI attachments. Providers validate every image in the
request, so one oversized image poisons the whole conversation: Anthropic drops
its per-image cap from 8000px to 2000px once a request carries many images, and
every later turn re-sends the same payload. Switching models does not help.
Normalize tool result images in AgentSession.afterToolCall, after the extension
tool_result hook so extension-injected images are covered too. Honors
images.autoResize, and keeps the original block when processing fails so an
unavailable image backend does not delete tool output.
Refs #5369
Assisted-By: devx/86bf3b09-9aba-4d03-8154-50fca3ffc9b5
The google-vertex and google-generative-ai adapters called
client.models.generateContentStream bare, so a transient 429/5xx before
the first token became a terminal errored assistant message instead of
being retried like in the Anthropic, OpenAI, Azure, and OpenRouter
adapters. Wrap the initial request in the shared retryProviderRequest
via a new retryGoogleRequest helper that also normalizes @google/genai's
ApiError, which has a status property but no headers property, so
retryProviderRequest's provider-error guard recognizes it.
Opt-in via the existing maxRetries stream option; default behavior is
unchanged.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Queued steer/followUp/nextRun items get a durable identity and retraction,
mirrored in both design variants so the diff stays mechanism-only:
- queue_enqueued acceptance returns the provisioned entryId; snapshots and
queue_update events carry QueuedItem { entryId, message }.
- New queue_cancelled record: without it, recovery would resurrect a
cancelled item (record-without-entry restores as pending). Validity rules
reject cancels of unknown or already-consumed items.
- cancelQueued(entryId) is one conditional mutation-line job; race-catalog
row 12 covers cancel-vs-consume with exactly two histories. Reduction now
also excludes abort-killed items (baseline omission).
- Adds the LaneRecord/NewRecord unions that sections 12/13 already
referenced but section 5 never defined.
Adopted from the effect-durable-agent comparison (pending-message identity
and cancellation), trimmed to the minimal slice.
Replace harness-v2.md with two candidate designs that share Parts I and II
verbatim and differ only in the Part III stepping mechanism:
- harness-v2-effects.md: straight-line async procedures; deterministic
stepping via a gated effect boundary (drive: "manual").
- harness-v2-generator.md: synchronous state machine; stepping via yielded
actions and an execution controller.
Both fold in the fixes for the baseline defects found during the audit:
per-lane mutation line with conditional commits (finish/steer/abort/queue
races), nextRun capture at acceptance, terminal-failure recovery, terminate
persisted on tool-result entries, move-first navigation commit (closes the
open question, removes the only multi-object atomic write), corrected v3
normalization, and #7339-aligned deferred redemption.
Only one variant will be implemented; diff the two files to see the
mechanism trade-offs in isolation.
