This file is intentionally mirrored in:
codex-session-transfer/references/common-interfaces.mdcodex-session-sync/references/common-interfaces.md
If either copy changes, treat that as a potential incompatibility risk and strongly recommend updating the counterpart copy in the same change.
Both skills must treat these objects as one coherent session unit:
- rollout transcript
jsonl threadsrow instate_5.sqlitesession_index.jsonlentrythread_dynamic_toolsrows when present
Both skills must understand this package structure as the baseline import surface:
session-skill-package/
package_manifest.json
README.md
INSTALL_REMOTE.md
metadata/
threads.jsonl
session_index.jsonl
thread_dynamic_tools.jsonl
path_localization.json
sessions/
skills/
skeleton/
required-directories.json
codex-session-sync may extend package interpretation, but should not silently break this baseline layout.
The following manifest semantics are shared:
format_versionpackage_kindminimum_working_set_onlycwd_filterthread_idsskills_includeddeferred_componentspreferred_installer_skill
New sync-only fields should be additive and optional for transfer compatibility.
For Windows paths, preserve the suffix starting at \\Documents\\ and replace the leading user-home prefix with the destination local home path.
If a path has no \\Documents\\ segment, leave it unchanged unless an explicit mapping is provided.
Any importer that materializes a local session copy may rewrite:
session_meta.idsession_meta.timestampsession_meta.cwdturn_context.cwdturn_context.sandbox_policy.writable_roots- embedded user
<environment_context>cwdvalues when present
Do not silently broaden transcript mutation without reflecting the change in both skills.
When a new local session must be created, both skills should follow the same policy:
- generate a new UUIDv7-based local session id
- derive the target rollout path from the new id timestamp
- preserve source sessions untouched
codex-session-sync may preserve an existing local session id only in fast-forward cases where no new branch session is created.
Both skills should preserve the transaction-journal concept for reversible filesystem and metadata changes:
- transaction id
- creation timestamp
- plan summary
- backup inventory
- reversible operations list
- terminal status such as prepared, completed, or rolled_back
If either skill modifies any shared interface listed here:
- mark the change as a potential incompatibility risk
- review the sibling skill for drift
- update the mirrored declaration in the sibling skill
- re-check docs, scripts, and handoff guidance for both skills