[Proposal] Versioned Session Action Export

[failuresmith]

What variant of Codex are you using?

CLI

What feature would you like to see?

Ask

Introduce a small, versioned export surface for persisted session actions.

Goal:

• Given a persisted session → return an ordered list of actions
• Make it a documented, stable contract for external tools
• Restrict V1 to data already persisted and reconstructible

Why

Codex already persists and reconstructs session history, but no surface is clearly defined as a stable contract.

This blocks tooling for questions like:

• What commands ran?
• What file changes occurred?
• What tool calls happened, and in what order?
• What can be safely replayed or inspected?

Rationale

A stable, versioned projection over persisted actions provides:

• a minimal reproducibility surface
• a safer alternative to depending on internal rollout formats
• a foundation for future debugging / incident tooling

Routing question

Where should this live?

• app-server (thread/read extension?)
• rollout layer (as backing projection)
• other surface if preferred

Additional information

Proposal

Expose a stable projection over persisted session history.

Possible entry points:

• CLI: export actions from a session
• API: return versioned action stream
• Extension of thread/read with a documented projection

Prefer: a projection layer over existing persisted data (not raw rollout JSONL).

Example schema (V1)

• session_id
• turn_id
• timestamp
• action_type
• tool_name
• command
• changed_paths
• status

Non-goals

• No reasoning or chain-of-thought
• No raw prompts by default
• No dashboards or analytics
• No new logging system if existing persistence suffices
• No full forensic completeness

Suggested V1 scope

Keep deliberately narrow:

• opt-in
• completed actions only
• minimal schema
• explicitly versioned
• derived from persisted session data

Likely includes:

• completed command executions
• completed file changes
• completed tool calls
• durable turn/session markers

Excludes:

• begin/request/delta events
• approval flows
• realtime ephemeral notifications

Grounding in current implementation

This proposal builds on existing behavior:

• Rollouts are persisted and replayable
• Persisted history is loaded into InitialHistory
• thread/read + includeTurns returns stored history
• persistExtendedHistory exists (without backfill guarantees)
• Rollout items are already projected into turns

At the same time:

• Persistence is selective (only certain “end” events)
• Many events are intentionally not persisted
• Realtime notifications are explicitly ephemeral
• Stored outputs are already sanitized/truncated

Preference:

• avoid making rollout JSONL the public contract
• avoid relying on OTEL as the primary user-facing interface
• expose a stable projection over persisted session history

[Mahkhmood9]

To be honest it seems pointless , and not usable

thats what , thirdparty tools like clawbot for or whatever

[Mahkhmood9]

@failuresmith Its seems to already happen

see the MEMROES option in codex

sometimes it even cites memorizes

**side nodes ** it feels like [word][word][word][word][injecting a prompt to cite a memory]

this is the feel I get from this codex option

(all tho I think my idea should be better, but likely ruins some benchmark, )

codex 5.4 is the the same kid as mini,,
mmini has a memory issue it sometimes forget and it tkaes it more time to do the task (like a 3 more tools calls )

[etraut-openai]

@Mahkhmood9, please stop spamming our issue tracker.

[Mahkhmood9]

for exmaple I used non openai on chromium codebase

I spent like 2 pro accounts weekly usage rate limit ,, becuase of a bug tat the other llm did

all it all to do is "See the current Git-uncommited code"----

but instead gpt 5.4

kept spewing... more and more and more code, like more code going to improve it

next I clean everything -- return the MASTER branch

I gave it access to a test file , that works in golang

i told it to use the QUIC golang implementation
I told it to keep executing the golang demo file

it worked first prompt , after I ... me the developer,,, had the talent to understand its slop over slop

but gpt 5.4 is able to work great with the currect prompt---

but I honestly BEGGGGGED IT I beg the llm to do I used the same wording before
--- but I had to start fresh, because it tried to use the current session tokens too hard

moral of the story, gpt 5.4 is able to impkemenet very complex code ideas c++ and udp socks5 is not well documented, so gpt 5.4 didnt used online refrences
it used good old .... large language next token prediection....

it understand to use rg , it understood how to crawl the chromium codebase ......

hereis the refrenced code
(AGAIN DONT COME AFTER MY ACCOUNT PLEASE ,,, I am not generating nodejs slop ,,, see me as imprvoing your dataset ! )
(I always share the code and allow data collection, to improve the models ---- see me as an artifact of training)
Sorry for making free accounts

islamjapan/chromium@972e368#diff-2ed71751e47fa36f67cfbc71f9c96174578201eb4b189038d7f2cae4a7cdbc16

**anyways I dont even know basic syntax in c++. I dont know how to deal with compiling this large codebase **

like how I am a person know to go to
@@ -27,11 +27,13 @@ SOCKSSocketParams::SOCKSSocketParams(

and know I should add
auth_credentials_(std::move(auth_credentials)),
std::optional auth_credentials,

and think about std:: and optional

**we reached AGI **

[jazzyalex]

Adding one downstream-tool perspective from Agent Sessions, which reads local Codex session history for search, transcript browsing, resume workflows, and subagent hierarchy display.

The most useful contract for external tools would be a versioned projection over persisted history, not the raw rollout JSONL shape. In practice, the hard part is distinguishing:

• actions that never became durable,
• actions that are durable but intentionally redacted/truncated,
• events that exist only as realtime app-server notifications,
• child/subagent sessions that should be represented as separate durable sessions with a parent edge,
• cwd/session identity changes that affect whether a resume command is meaningful.

A small V1 projection would already help if it exposed stable identifiers and ordering:

• session_id
• turn_id
• timestamp
• action_type
• tool_name
• status
• cwd
• changed_paths
• optional parent_session_id / child_session_id edges for subagents

I would keep prompt text and reasoning out of V1 by default. For local history tools, the highest-value data is usually action ordering, durable status, cwd/path identity, and lineage. That is enough to answer "what happened in this session?", "which subprocess changed this file?", and "can this session be resumed safely?" without making internal rollout files a public API.

Project for context: https://github.com/jazzyalex/agent-sessions