Skip to content

Explore bounded rollout recall and model-assisted session archaeology #809

Description

@shiny-code-bot

Objective

Explore whether Codex Lab should give an agent a first-class, bounded way to inspect and reason over its own persisted session rollout, including history that is no longer present verbatim in model context after compaction.

This issue is an exploratory product and architecture record, not an implementation commitment. It exists so the idea, existing substrate, risks, and possible slices remain recoverable until dogfood evidence or roadmap prioritization justifies work.

Finish Line

The exploration is complete when Codex Lab has a documented recommendation covering:

  • the user and agent workflows that require rollout recall
  • the boundary between deterministic retrieval and model-assisted synthesis
  • safe and bounded access to active, compacted, resumed, and archived history
  • privacy, prompt-injection, secret-handling, and retention constraints
  • whether cheap cloud models, local models, or the parent model should perform synthesis
  • how local LLM-backed agents should relate to the unified first-class agent system
  • the smallest reviewable implementation slices, if the feature is promoted

No production code, milestone assignment, or delivery date is required to satisfy this exploratory issue.

Current Status

State: exploratory and waiting as of August 30, 2026. The feature is still in thought and is not selected for implementation.

The motivating observation is that agents are sometimes manually directed to read rollout JSONL files when they need details lost through context compaction or when diagnosing a long-running session. The data largely exists, but there is no purpose-built, model-facing, bounded self-recall interface.

Next action: none until concrete dogfood friction, privacy requirements, or roadmap interest promotes the exploration. When revisited, begin with a fresh architecture audit against the then-current rollout, thread-store, memory, structured-request, and agent-provider implementations.

Motivation

  • Active model context and persisted rollout history are different products. Compaction replaces model-visible history with a reduced representation while older rollout records remain available on disk.
  • Manual shell inspection works but is cumbersome, path-oriented, easy to over-read, difficult to cite precisely, and inconsistent across active, compressed, resumed, and archived sessions.
  • A first-class recall surface could help agents recover prior decisions, locate tool results, explain why a path was chosen, audit long-running work, and diagnose compaction-related omissions.
  • Model prices, context windows, and available local models change frequently. The retrieval contract should not depend on a permanent model name.

Existing Substrate

Codex Lab already contains much of the underlying machinery:

  • Rollouts persist canonical messages, reasoning records, tool calls/results, compaction checkpoints, turn context, and session metadata, subject to rollout persistence policy.
  • Thread and state storage can resolve thread identity and rollout paths; paginated history projection and keyset-query groundwork exists.
  • thread/search searches rollout contents, although it is a cross-thread user-facing search rather than a self-scoped agent recall API.
  • The memories pipeline performs bounded per-rollout filtering, model extraction, secret redaction of generated memory, leases, concurrency control, retry backoff, and later consolidation. It operates on eligible idle rollouts rather than interactive recall of the active session.
  • Add a lightweight structured LLM request side channel #319 provides a stateless structured model-request path on main, suitable for bounded synthesis without creating another coding-agent thread or rollout.
  • Third-party agents have a first-class command-backed lifecycle, and LM Studio/Ollama exist as configurable model providers.
  • Local model tooling in codex-skills already defines rollout-oriented roles such as rollout_scout, proving the workflow is practical, but local models are not yet dynamically discovered first-class selectors in unified agent.create.

Candidate Architecture

Keep retrieval deterministic and independent from model selection:

self-scoped rollout query -> bounded cited evidence packet -> optional synthesis
                                                        -> local model
                                                        -> cheap cloud model
                                                        -> parent model

Retrieval Layer

A possible rollout_query or similarly named internal tool would:

  • bind to the current session/thread by default rather than accepting an arbitrary rollout path
  • distinguish current effective post-compaction context from older historical rollout evidence
  • support bounded filters such as text query, turn range, item kind, tool name, and recent tail
  • return structured provenance such as thread id, turn id, item id or rollout ordinal, timestamp, and compaction boundary
  • enforce hard caps on matches, records, bytes, scan time, and returned model-visible content
  • report truncation and the portion of history actually searched
  • default-exclude or redact sensitive developer messages, credentials, raw command environments, and large tool payloads
  • treat retrieved content as untrusted historical evidence, never as higher-priority instructions

Synthesis Layer

An optional synthesis step would consume only the bounded evidence packet. It should select a capability role such as rollout_scout rather than hard-code a model. Possible routing policies include:

  • local_only for private material
  • prefer_local with explicit fallback reporting
  • lowest_cost among eligible structured-output models
  • parent_model when consistency matters more than cost

For very large histories, synthesis should use filtered chunks and map/reduce-style consolidation similar to the existing memory pipeline rather than sending raw rollout JSONL as one prompt.

Local And Cheap Model Considerations

  • Long context is useful but is not a substitute for deterministic filtering, citations, and output bounds.
  • Local inference is attractive for private rollout contents and may be inexpensive after model load, but cold-load time, memory pressure, model compatibility, malformed output, and missing final messages require typed failure handling.
  • Cloud model routing should be explicit about destination, estimated input size, privacy policy, and fallback behavior.
  • Local model support should ultimately integrate with the first-class agent/provider system instead of remaining a rollout-specific subprocess special case.
  • The recall feature should remain functional without any synthesis model; deterministic evidence retrieval is the durable core capability.

Safety And Product Risks

  • Rollouts can contain source code, private prompts, tool output, filesystem paths, credentials, cookies, command environments, and other sensitive data.
  • Historical user/tool text can contain prompt injection. Reintroducing it into context must not restore its authority.
  • Reading the entire live file may race active writes or produce inconsistent partial records.
  • Raw rollout format is a persistence format, not necessarily a stable public model-tool contract.
  • Unbounded retrieval could defeat compaction, increase cost, destabilize prompt caching, and create recursive context growth.
  • Cross-thread or parent/child-agent recall raises separate authorization and information-boundary questions and should not be assumed by an initial self-only design.

Possible Future Slices

If promoted, split implementation into reviewable work rather than landing the whole concept at once:

  1. Add deterministic, self-scoped, bounded current-thread history query with citations and compaction-aware views.
  2. Route app-server/thread-store pagination through the same bounded retrieval substrate where appropriate.
  3. Add optional structured synthesis with capability-based local/cheap model routing and typed failures.
  4. Promote discovered local LLM models into unified agent.create with provider, model, context, lifecycle, and requested/effective provenance.

These are candidate slices only. They should become separate implementation issues if and when the exploration is promoted.

Exploration Questions

  • Which concrete dogfood failures cannot be solved by existing memory summaries, thread/search, or ordinary context compaction?
  • Should an agent be allowed to inspect only its own thread, or also explicit parent/child threads?
  • Is current in-memory history, canonical persisted rollout history, or reconstructed user-visible thread history the correct source for each query mode?
  • Which item classes are safe by default, and which require explicit opt-in?
  • How should citations survive compaction, rollback, resume, archive, and rollout compression?
  • Should synthesis run inline, as a background worker, or through the stateless structured-request API?
  • Should local model discovery be a provider capability, an agent selector registry, or both?
  • What evaluation proves that model-assisted recall improves decisions rather than merely adding persuasive summaries?

Relationships

Decisions Recorded So Far

  • Document the feature now but do not schedule implementation.
  • Retrieval should be deterministic, self-scoped, cited, and bounded before any model is involved.
  • Cheap or local models are optional synthesis workers, not the source of truth for locating history.
  • Model routing should use capabilities and privacy policy rather than a fixed model name.
  • First-class local-agent support is broader than rollout recall and should remain separable from the retrieval API.
  • Do not expose arbitrary rollout paths or inject entire raw rollouts into model context as the initial design.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    planDurable planning issueplan:donePlan completed or superseded

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions