Allow stored Codex threads to be associated with a project cwd after planning

Open 💬 4 comments Opened May 18, 2026 by Lee-take

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Proposal

Please consider adding a supported way to update a stored Codex thread's project or workspace association after the thread has already been created. One small backend primitive for this would be allowing stored thread metadata updates to patch the thread cwd.

Motivation

A common workflow is to start with early planning in a standalone Codex conversation before the repository or project directory exists. After the project folder is created, the useful planning context can remain outside the project/workspace it now belongs to.

Today, the practical workaround is to ask Codex to generate context files and write them into the new repository. That helps, but it still leaves the original conversation detached from the workspace. A supported metadata update would make it possible for clients to build a more natural "attach", "move", or "promote this thread to a project" flow without touching local sqlite state directly.

Possible implementation direction

The thread model already persists cwd, and thread/list already supports cwd-based filtering. The existing thread/metadata/update method also patches sqlite-backed thread metadata for gitInfo.

One narrow approach would be to extend thread/metadata/update with an optional cwd field, resolve it consistently with existing cwd handling, and persist it through the existing thread metadata patch path.

Benefits

Preserves planning context when a project is created after the initial conversation.
Avoids direct client-side edits to local sqlite state.
Gives Codex clients a small backend primitive for future UI workflows that attach or move a thread into a workspace.
Keeps the behavior scoped to metadata rather than changing thread contents or replaying conversation history.

I understand that external code contributions are by invitation only. I am happy to keep this as a design discussion unless the Codex team thinks a small PR would be useful.

View original on GitHub ↗

4 Comments

Lee-take · 3 months ago

I prepared a small implementation branch to make the proposal concrete:

I attempted to open it as a draft PR against openai/codex, but GitHub returned a permission error for CreatePullRequest. That is completely understandable given the contribution policy. I am leaving the branch here only as a reference implementation in case it is useful for the team while evaluating the proposal.

Implementation summary:

Adds optional cwd support to thread/metadata/update.
Resolves the provided cwd through the existing absolute-path helper before persisting it.
Reuses the existing StoreThreadMetadataPatch path, which already supports cwd updates in the thread store.
Keeps existing gitInfo patch semantics unchanged.
Rejects empty metadata updates when neither cwd nor gitInfo is provided.
Updates app-server docs and generated protocol schema fixtures.

Validation on a clean worktree based on latest origin/main (4ca60ef):

cargo fmt --all -- --check passed. Rustfmt emitted the existing imports_granularity = Item nightly-channel warning.
cargo test -p codex-app-server --test all thread_metadata_update passed: 9 tests.
cargo test -p codex-app-server-protocol passed: 209 unit tests and 2 schema fixture tests.

Thank you again for considering the workflow. I would be happy to adjust the proposal or follow whichever process is most helpful for the Codex team.

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#22345
#21886
#21882

Powered by Codex Action

Lee-take · 3 months ago

Thank you for the duplicate check.

I reviewed the suggested issues:

#22345 is the closest match for the product-level request to move chats into/out of Projects. I noticed it was closed as a duplicate of an earlier request.
#21886 is related, but appears to focus more on importing or rebinding existing Codex CLI sessions into Codex App projects.
#21882 is also related, but focuses on recovering from a stale or missing filesystem cwd after a project folder is renamed.

I also found #13836 and #20115, which seem to cover the broader product workflow around Projects, movable chats, shared project context, and archiving/attaching conversations to project folders.

This issue is meant to be narrower than the full product request: it documents one possible backend/protocol primitive, thread/metadata/update support for cwd, that could help implement future attach/move/promote flows without direct sqlite edits. I added a reference implementation branch in the earlier comment only to make that technical option concrete.

If the maintainers prefer to keep all discussion consolidated under #13836 or #20115, I am happy to close this issue and continue there. Thank you again for taking a look.

boombx403-byte · 9 days ago

Hi @Lee-take, I'm testing a local-first, read-only diagnostic tool (Codex Rescue Alpha5) against local session persistence and rollout anomalies. It evaluates schema compatibility, tool correlation, and state consistency without modifying the original rollout or SQLite databases.

If the affected session is still present locally, you can run:

pip install codex-rescue==0.1.0a5
codex-rescue doctor --latest

No raw data is needed; please redact any private repository paths before sharing results.