[Feature Request] Add repository-aware, sanitized task handoff across workspaces
What variant of Codex are you using?
Codex App and Codex CLI on macOS. The requested state contract should be shared
across both variants.
What feature would you like to see?
Summary
Add a repository-aware, sanitized task handoff that can move the useful context
of an existing Codex task into a new task associated with another workspace or
Git repository.
The handoff should transfer a compact, user-reviewable operational summary, not
replay or duplicate the complete session history. The destination task must
re-read its repository instructions and revalidate its filesystem, sandbox,
Git, and remote authority before taking action.
Problem
Long-running engineering work often starts in one repository and produces a
follow-up that belongs in another repository. Today, users can manually fork or
resume a task with a different working directory, but this creates several
risks:
- the copied history can be very large and contain irrelevant tool output;
- source-repository assumptions can be mistaken for current destination state;
AGENTS.mdand other destination instructions may not receive sufficient
priority;
- filesystem and remote permissions can appear to carry over implicitly;
- forks duplicate historical messages, which complicates later analysis;
- private paths, task identifiers, logs, or secrets may be copied unnecessarily.
In one anonymized local workflow, 27 sessions contained 563 deduplicated user
requests, 25 interruptions, and about 0.38 GiB of JSONL history. Two session
forks duplicated prior history. This is manageable as raw storage, but it is not
a good handoff protocol or a reliable system of record.
Proposed behavior
Provide an App action such as Hand off to repository... and a matching CLI
operation, for example:
codex handoff --to /path/to/destinationBefore creating the destination task, show a sanitization preview containing:
- current goal and acceptance criteria;
- accepted decisions and rejected approaches;
- completed work and open work;
- known blockers and the exact next safe action;
- user-selected artifact references;
- source task identifier and a new handoff identifier.
Raw tool output, secrets, credentials, absolute private paths, unrelated
conversation history, and full JSONL replay should be excluded by default.
Users should be able to remove individual fields before confirming.
The destination task should then:
- bind itself to the selected workspace and resolved Git root;
- read destination instructions such as
AGENTS.mdbefore acting; - inspect branch, worktree, remotes, and current repository state;
- label imported information as historical context until locally verified;
- request new filesystem, execution, remote-write, PR, or merge authority;
- preserve the source task unchanged and link both tasks for audit and return.
If the destination path conflicts with the selected workspace, the handoff must
stop for confirmation rather than silently changing repositories.
Safety and privacy properties
- No implicit inheritance of remote or merge authority.
- No write before destination instructions and Git state are checked.
- User-visible redaction preview before handoff creation.
- Local-only handoff package by default.
- Versioned, integrity-checked handoff schema.
- Clear distinction between imported history and verified current facts.
- Source task remains recoverable and unchanged.
Additional information
This request complements, rather than replaces, existing requests:
- #12464 proposes changing the current working directory inside one session.
- #28218 proposes automatic checkpointing and interrupted-session recovery.
- #29356 addresses operational continuity during context compaction.
- #31245 requests warnings for prompt/workspace conflicts.
- #33814 reports inconsistent CWD metadata after a managed-worktree handoff.
The proposed feature focuses on an intentional transition between repository
contexts with minimum necessary context, explicit sanitization, instruction
reload, and renewed authority. It should not be implemented as a silent /cwd
change or a complete session-history copy.
4 Comments
The repository-aware and sanitized parts are the load-bearing constraints here. A good handoff should carry the minimum operational state — goal, decisions, open work, selected artifacts and a new handoff ID — while forcing the destination to reload AGENTS.md, inspect the Git/worktree state and request fresh authority. I would also label every imported item as historical until locally verified, rather than letting a copied session imply that paths, credentials or remote permissions still apply. I build cmdop, so I am biased — our machine/agent contact model runs into the same session-identity versus control-authority boundary. https://cmdop.com/products/messenger
A cross-platform use case would make this feature especially valuable.
When developing an application intended to run across multiple platforms, I often need to move the same project between Windows, macOS, and potentially another development machine. Git/GitHub already handles source-code synchronization well, but the useful Codex development context does not move with the repository as seamlessly.
An ideal workflow would be:
The handoff does not need to copy the full conversation. A compact project checkpoint would be preferable, containing only information such as:
For privacy and security, machine-specific and sensitive information should be excluded or sanitized by default, including usernames, absolute local paths, computer/host names, credentials, API keys, tokens, environment secrets, unrelated shell history, and other local identifiers. A user-reviewable preview before synchronization/handoff would be ideal.
The destination machine should then independently inspect its filesystem, repository state, dependencies, platform-specific requirements, and permissions instead of assuming the source machine's environment is still valid.
In short, the desired model is:
Git synchronizes the code; Codex synchronizes the minimum safe development context.
That would make Codex substantially easier to use for real cross-platform application development across Windows, macOS, and multiple PCs.
A cross-platform use case would make this feature especially valuable.
When developing an application intended to run across multiple platforms, I often need to move the same project between Windows, macOS, and potentially another development machine. Git/GitHub already handles source-code synchronization well, but the useful Codex development context does not move with the repository as seamlessly.
An ideal workflow would be:
The handoff does not need to copy the full conversation. A compact project checkpoint would be preferable, containing only information such as:
For privacy and security, machine-specific and sensitive information should be excluded or sanitized by default, including usernames, absolute local paths, computer/host names, credentials, API keys, tokens, environment secrets, unrelated shell history, and other local identifiers. A user-reviewable preview before synchronization/handoff would be ideal.
The destination machine should then independently inspect its filesystem, repository state, dependencies, platform-specific requirements, and permissions instead of assuming the source machine's environment is still valid.
In short, the desired model is:
Git synchronizes the code; Codex synchronizes the minimum safe development context.
That would make Codex substantially easier to use for real cross-platform application development across Windows, macOS, and multiple PCs.
Thanks for adding this — your cross-platform example captures the use case very well.
The distinction between Git synchronizing the repository and Codex carrying only the minimum safe project context is exactly what I had in mind. I especially like the idea that the destination machine must revalidate its environment, dependencies and permissions instead of treating the previous machine state as authoritative.
Windows ↔ macOS ↔ another development machine is also one of the scenarios that motivated this request. Thanks for spelling it out so clearly!