Codex conversation silently loses its Codeg index entry when a new session starts in the same conversation record

[Charlie-1909]

Bonjour,

Thank you for the quality of Codeg's development and for the regular improvements made to the project.

I would like to report unexpected behavior affecting the preservation of a Codex conversation.

Environment: Codeg v0.26.0, Windows 11, Codex ACP adapter 1.4.0, Codex ACP agent version 1.1.9.

Diagnosed by: investigated and written by Codex running as the active agent inside a Codeg session, at the human user's request. Findings below come from Codeg's runtime logs, SQLite database and Codex's local transcripts. User clicks and keyboard events are not logged, so no claim is made about the initiating UI action.

Symptom

A Codex conversation that had been active for approximately 49 minutes disappeared from Codeg's conversation index when a short new message was sent.

The user did not knowingly request a new conversation and believed the message was being sent to the existing conversation.

A new Codex session was created, but Codeg did not preserve the previous conversation as a separate indexed row. The original Codex transcript still exists intact on disk and can be read manually.

Observed timeline

All timestamps below are local time in France on 2026-08-16.

• 17:11:36 — Codeg conversation row 107 is created for the original Codex session.
• 17:59:59 — The original session completes its final turn normally.
• 18:00:02 — Codeg disconnects the original Codex session.
• 18:00:02 — Codeg immediately opens a Codex connection with no session id.
• 18:00:45 — Sending the next message creates a new Codex session id.
• The previous conversation is no longer present as a separate row in Codeg.

There is no Codex-side error, deletion request, limit event or abnormal turn termination.

Session identifiers

Original session:

01a00b20-00b6-73f1-a195-16151321bba2

New session:

01a00b4d-2ff8-7e42-b336-f353dc9558ee

Database evidence

Before the event, the SQLite write-ahead log repeatedly shows:

conversation id: 107
title: nouveauté de cette nouvelle version de codeg...
external_id: 01a00b20-00b6-73f1-a195-16151321bba2
created_at: 2026-08-16T15:11:36.873170600+00:00

After the event, the live conversation table shows:

conversation id: 107
title: tu peux faire 2 couleur...
external_id: 01a00b4d-2ff8-7e42-b336-f353dc9558ee
created_at: 2026-08-16T15:11:36.873170600+00:00

The row id and original creation time were retained, while the title and external session id were replaced. No second conversation row was created for the new session.

This is not merely a hidden or completed conversation: querying the live database for the original external id returns no row.

Runtime log evidence

The original session ends normally:

turn_complete
session=01a00b20-00b6-73f1-a195-16151321bba2
stop_reason=end_turn
background_outstanding=0

Three seconds later, Codeg disconnects it:

disconnect
status_changed
Connected -> Disconnected

Codeg then opens a connection with:

session_id=None

The next message creates the new external session id. No delete event, crash or error is logged.

Codex transcript evidence

The original Codex transcript ends with a normal task_complete event. It contains:

• no request to close the session;
• no request to delete the conversation;
• no command to create a new session;
• no service, authentication or context-limit failure.

The full original transcript remains on disk.

Initiating action is unknown

Codeg does not log mouse clicks or keyboard events.

The user may have unknowingly triggered:

• the New Conversation button;
• the default Ctrl+T New Conversation shortcut;
• another UI path.

There is no evidence of the two-key sequence Ctrl+W, then Ctrl+T.

Regardless of the initiating action, starting a new conversation should not remove the previous conversation's index entry or reuse its database row.

Expected behavior

When a new Codex session starts:

1. Create a new Codeg conversation row.
2. Preserve the previous conversation row and external session id.
3. Keep the previous conversation visible and reopenable from history.
4. If a destructive replacement is intended, require explicit confirmation.

Actual behavior

The existing Codeg row appears to have been reused for the new Codex session.

The previous conversation becomes inaccessible through Codeg even though its native Codex transcript still exists.

A user without knowledge of the local transcript store would reasonably believe the conversation had been deleted.

Impact

• Conversation history becomes inaccessible from Codeg.
• The visible title and session id no longer describe the row's original creation.
• Codeg's database and Codex's transcript store disagree about which conversations exist.
• Project context can appear permanently lost.
• The failure is silent: no warning says that the active conversation is being replaced.
• Post-hoc recovery requires manual inspection of Codex JSONL transcripts.

Suggested directions

1. Never update an existing conversation row with a different non-null external session id.
2. Insert a new conversation row whenever an ACP connection moves from session_id=None to a newly created session id.
3. Add an integrity check: if the external id changes, preserve the previous row and create a new one.
4. Log the UI action that initiates a new conversation.
5. Add a regression test covering an existing completed Codex conversation followed by a new session in the same folder and pane.
6. Add a recovery/import path for native transcripts whose external ids no longer exist in Codeg's database.

I can provide redacted runtime-log extracts, SQLite WAL evidence or test a fix.

Thank you for your work and for reviewing this report.