Session logs on your computer

DataMind Oda keeps every chat's lasting record as session log files on your computer. This page shows where the files live, how Oda names and keeps them, and how to open, back up or inspect them. For the messages Oda shows when a log has a problem, see Session log problems.

Where session logs live

All of your session logs sit under a single folder on the computer; this page calls it the log folder.

• The log folder has no default: it is set for your installation, and every chat is saved under it. If you are not sure which folder was chosen, ask your DataMind OS administrator.
• Inside it, chats are grouped by the folder they work in. The group's folder name is wrapped in --, and a chat with no working folder sits in a group named _no-cwd.
• Every chat has a folder of its own. Its name is made from the chat's id, changed only as much as needed so the id stays safe as a folder name; nothing in an id can point outside the log folder.

A chat with more than one generation of its log, compression on, looks like this:

<log folder>/
  --<working folder>--/
    <chat folder>/
      session.jsonl.zstd
      session.v4.jsonl.zstd

A chat with compression off keeps the same names without .zstd.

How log files are named and kept

• The oldest format's file keeps the plain name session.jsonl, with no version in it.
• Later formats put their version into the name, as in session.v1.jsonl. Current Oda writes version 4, so a log it saves is named session.v4.jsonl, with .zstd added when compression is on.
• Oda reads only files with these exact names. A renamed copy, such as session.v1.backup.jsonl, session.v01.jsonl or session.V1.jsonl, is not treated as a log.
• When Oda saves a chat whose log was written by an older format, it adds the current file beside the old one, and the old file stays exactly as it was. One chat can have several generations side by side, and the newest file is the chat's current state.
• Oda never renames, replaces, moves or deletes a generation it has already saved.
• A log's first line identifies the chat: the format version, the chat's id and creation time, the folder it works in, and how it started, including any history inherited from another chat. Oda checks this line before trusting the rest, and a file whose first line breaks these rules, for example a folder that is not an absolute path, is refused rather than guessed at.
• Values inside a log are stored exactly as they were written. Oda refuses to save a value it cannot keep exactly, instead of storing a changed version.

Opening a chat written by a different version of Oda is covered in Opening sessions from other versions.

When a chat first reaches disk

• A new chat writes nothing at all until it first has content to save. A chat you never used leaves no files, even if Oda stops suddenly.
• The first save writes the file's first line, which identifies the chat, and the first events. Every later save adds to the end of the file.
• Once a save finishes, what it stored is stable: Oda never rewrites it, and a later read never shows an older state than an earlier one.
• If Oda stops in the middle of a save, the unfinished piece at the end is left aside and cleared on the next save; see Recovering sessions after a crash.

Compressed and plain logs

• Compression is on by default. A compressed log is stored as a series of Zstandard frames with checksums, and its name ends in .zstd; read these logs through Oda.
• With compression off, a log is plain text: one JSON object per line, which you can open in a text editor.
• A log folder keeps one form: all compressed or all plain. Oda refuses a log stored in the other form instead of reading it wrongly, and a folder cannot be switched between forms; use a separate folder for each form.

One writer at a time

• Oda allows one writer per chat at a time, and the rule holds across every copy of Oda running on the computer.
• Reading a chat is never blocked by the writer.
• A lock ends with its process: if the process holding it stops, the next writer can take the chat over at once.
• On some systems, a small file named session.lock sits in a chat's folder while the chat is being written, and it can stay after the writer releases it. If a chat stays locked because the process holding it cannot continue, deleting this file frees the chat for the next writer. Do this only when you are sure that process will not write the chat again.

Nothing is deleted automatically

• Oda never removes or trims log files, older generations included. There is no cleanup, no retention limit and no delete-all action, so files stay until someone removes them.
• Listing the logs a folder holds takes longer as the folder stores more chats.

Keep a copy of your chats

• Copy the whole log folder to a safe place. Every chat folder is complete on its own, older generations included, so the copy holds whole chats.
• The newest file in a chat's folder is that chat's current state.
• To use a copy, keep the folder shape and the saved form: a log stays in its chat's folder under its group, and a folder keeps one form. Oda refuses a log in the wrong place or the wrong form rather than read it wrongly.
• To copy a single chat, download it from the chat's menu; see Download a chat log.

Reading part of a log

• Oda reads a log in windows, not all at once. A window asks for a starting position and a length.
• The position is the sequence number of the first event to return; the default is the start of the log. The default length is the rest of the log.
• A position at or past the end returns nothing; that is not an error.
• Both values must be whole numbers of zero or more. Anything else is refused with read offset must be a non-negative safe integer, got <v> or read length must be a non-negative safe integer, got <v>, depending on the value.
• Reading never changes a log, and a later read never shows an older state than an earlier one.

The full format of a log, and what its records hold, is covered in Chat log format.

Values Oda keeps to reopen a chat quickly

Besides the log, Oda keeps small current values built from it, so it can show a chat's state without reading every event again.

• A set of these values carries a position: the place in the log that every value in the set accounts for. For a chat with no events yet, the position is -1.
• Some of these values stay inside Oda and are never shared with other programs.
• Oda can save checkpoints of these values, so opening a chat does not work through the whole log. A checkpoint that no longer fits the log, for example one from a different version or after the log changed, is not served as current: Oda builds the values again from the start.
• A value taken from a saved checkpoint can trail the log, so it counts as a hint until its version is checked; it is never wrong.

Questions, answered

Where are my session logs kept on this computer?

All of a chat's logs live under one log folder on the computer. Inside it, chats are grouped by the folder they work in, and every chat has a folder of its own. The log folder has no default: it is set for the installation, so if you are not sure which folder was chosen, ask your DataMind OS administrator.

When does a chat first reach disk?

A chat writes its first file only after it first has content to save. Until then nothing exists for it, and a chat you never used leaves no files even if Oda stops suddenly. The first save writes the file's first line and the first events; later saves add to the end.

Which file is my chat's current state, and what are the others?

A chat can have several generations of its log side by side: session.jsonl from the oldest format, and session.v<N>.jsonl files from later ones, with .zstd added when compression is on. The newest file is the chat's current state, and the older ones stay exactly as they were; Oda never renames, replaces, moves or deletes them.

What is the session.lock file?

On some systems, Oda keeps a small file named session.lock in a chat's folder while the chat is being written, to keep one writer at a time. It can stay there after the writer releases it. If a chat stays locked because the process holding it cannot continue, deleting this file frees the chat for the next writer; do this only when you are sure that process will not write the chat again.

Does Oda ever delete or trim old log files?

No. Oda keeps every generation, and there is no cleanup, no retention limit and no delete-all action. Log files stay until someone removes them, so remove what you no longer need yourself and keep copies of what matters.

How do I keep a safe copy of my chats?

Copy the whole log folder to a safe place. Every chat folder is complete on its own, older generations included, so the copy holds whole chats. To use the copy, restore it keeping the folder shape and the same form; Oda refuses a log kept in the wrong place or the wrong form rather than reading it wrongly.

Can I open a log file in a text editor?

Yes, when compression is off: the log is plain text, one JSON object per line. With the default compression, read the chat in Oda, because the compressed form is built to be read by Oda. Do not edit a log file by hand: Oda checks the log files it opens and refuses one that no longer passes its checks rather than guess.

I renamed or moved a log file and Oda does not see it. Why?

Oda reads a log only under its exact generation name and inside its chat's folder, in the shape and form it saved. A renamed copy, such as session.v1.backup.jsonl, is not treated as a log, and a file moved out of place is refused. Restore the original name and place from your backup, or keep the file for support.

How does Oda reopen a long chat without reading its whole log?

Oda keeps small current values built from the log and can save checkpoints of them, so opening a chat does not work through every event again. A checkpoint that no longer fits the log is not served as current; Oda builds the values again from the start. A value from a checkpoint can trail the log, but it is never wrong.

Does everything in my chat's log reach the model?

No. The model's history is built from your messages, Oda's answers, and its tool calls and results. Records kept for the file only never enter it, such as approval decisions, your feedback, permission and plan choices, the changed-files list, file-restore notes, scheduled-run markers and hook records.