Codex App cannot create visible project threads for newly initialized local directories

Summary

I am building an inbox style workflow for Codex App:

1. A saved Codex App project acts as an inbox/workbench.
2. The inbox receives unrelated incoming tasks.
3. For each task, the inbox creates a new project directory on disk.
4. The inbox archives source materials into that directory and generates a project-level AGENTS.md.
5. A new Codex thread should then be started for that specific new project directory, so the new thread can work with clean context and the correct cwd.

The current thread-management behavior makes this difficult:

• create_thread cannot create a new project-scoped thread using a newly created local directory unless that directory is already a saved Codex App project.
• codex exec -C <new-project-dir> can create a thread whose cwd is correct and whose thread_id can be read through read_thread.
• However, that CLI-created thread does not appear in the Codex App sidebar/thread list, cannot be found with list_threads(query=...), and cannot reliably be managed/archived from the App session.

This leaves no clean path for “create a new directory, then immediately create a visible App thread for it”.

Desired workflow

From a saved inbox project:

saved inbox project
  receives task
  creates new project directory
  writes AGENTS.md and material index
  starts a new Codex thread for that directory
  user sees the new thread in Codex App sidebar

Expected outcome:

• The new thread uses the new directory as cwd.
• The new thread loads the new directory's AGENTS.md.
• The new thread is visible in Codex App.
• The new thread is searchable/listable.
• The new thread can be read, continued, renamed, pinned, or archived through thread-management APIs.

Actual behavior

Experiment A: App create_thread with newly created directory

I created a temporary project directory on disk and attempted to call create_thread with that path as projectId.

Result:

• create_thread failed with Unknown projectId.
• The response indicated that projectId must be one of the App's already saved projects.

Observed implication:

• A newly initialized project directory cannot immediately be used as a Codex App project thread target.
• There appears to be no available thread-management API to register or save a newly created directory as a project first.

Experiment B: App create_thread using saved inbox projectId

I then used the already saved inbox project as projectId, and passed the real new project directory inside the prompt.

Result:

• create_thread succeeded.
• read_thread succeeded.
• The thread completed and confirmed it could read the generated project files.
• However, the thread cwd remained the inbox project, not the new project directory.

Observed implication:

• This works as a fallback, but the thread does not truly run in the new project directory.
• The prompt must manually instruct the agent to read files from another path.
• This is less robust than having the thread's cwd be the real project directory.

Experiment C: CLI codex exec -C <new-project-dir>

I tested:

codex exec -C "<new-project-dir>" `
  -m gpt-5.4-mini `
  --config model_reasoning_effort="low" `
  --skip-git-repo-check `
  --output-last-message "<output-file>" `
  --json "<prompt>"

Result:

• CLI returned a JSONL event containing:

{"type":"thread.started","thread_id":"019e8797-5193-7d71-9ec5-6809b6d95361"}

• The thread cwd was the new project directory.
• The thread read:
• AGENTS.md
• 00-原始材料/材料索引.md
• The final response contained the expected marker:

CLI_THREAD_E2E_OK

• Codex App read_thread(threadId=...) could read this CLI-created thread.

However:

• list_threads(query=threadId) returned no matching threads.
• list_threads(query=CLI_THREAD_E2E_OK) returned no matching threads.
• The thread did not appear in the Codex App sidebar.
• Attempting to archive it from the App session failed with a manager/registration error.

Observed implication:

• CLI-created threads are stored enough for direct read_thread(threadId) access.
• But they are not surfaced through App sidebar/list/search.
• They are also not fully manageable from the App session.

Current workaround

I currently have to choose between two imperfect paths:

Option 1: App-visible thread

Use create_thread with an already saved project such as the inbox project.

Pros:

• Visible/manageable in App.
• Can use App thread tools.

Cons:

• cwd is not the newly created project directory.
• The real project path must be passed in the prompt.
• The thread depends on instruction discipline to avoid using inbox context.

Option 2: Correct cwd thread

Use codex exec -C <new-project-dir>.

Pros:

• Correct cwd.
• Correct project-level AGENTS.md.
• Clean project execution context.
• read_thread(threadId) can inspect it.

Cons:

• Not visible in App sidebar.
• Not discoverable with list_threads.
• Not reliably manageable/archivable from App.
• Must manually record threadId in a task ledger.

Why this matters

This affects workflows where Codex is used as a task router or project initializer.

For example, in legal/patent/document workflows, each incoming task may be unrelated. Keeping all tasks in the same inbox thread causes:

• context pollution,
• unnecessary token use,
• risk of cross-project contamination,
• loss of clear handoff boundaries.

The desired pattern is:

Inbox thread = collect and initialize only
Project thread = analyze and execute inside the project directory

But the current App/thread behavior prevents a fully clean and visible handoff.

Requested improvements

Any of the following would solve or greatly improve the workflow:

1. Allow create_thread to accept an arbitrary local directory path as a project target, even if it is not yet a saved App project.
2. Add an API/tool to register/save a local directory as a Codex App project, then create a thread for it.
3. Make codex exec -C <dir> threads appear in the Codex App sidebar/list.
4. Make CLI-created thread IDs discoverable through list_threads.
5. Make CLI-created threads fully manageable from App thread tools:

• read_thread
• send_message_to_thread
• set_thread_title
• set_thread_pinned
• set_thread_archived

1. Provide an official handoff-thread flow:

• source project/thread creates a new directory,
• initializes files,
• starts a new visible App thread in that directory,
• records the new thread ID.

Minimal reproduction

1. Start in a saved Codex App project, e.g.:

E:\...\workspace\inbox

1. Create a new directory:

E:\...\workspace\new-project

1. Add:

new-project\AGENTS.md
new-project\00-原始材料\材料索引.md

1. Attempt App thread creation with projectId = E:\...\workspace\new-project.

Actual:

Unknown projectId

1. Run CLI:

codex exec -C "E:\...\workspace\new-project" --json "Read AGENTS.md and reply OK"

Actual:

• CLI returns thread.started.thread_id.
• read_thread(threadId) works.
• App sidebar does not show the thread.
• list_threads(query=threadId) does not find it.

Expected behavior

After creating a new project directory, there should be a supported way to start a new visible Codex App thread whose cwd is that directory.

Ideally:

create_thread({
  target: {
    type: "localDirectory",
    path: "E:\\...\\workspace\\new-project"
  },
  model: "...",
  thinking: "..."
})

Or:

register_project("E:\\...\\workspace\\new-project")
create_thread({
  target: {
    type: "project",
    projectId: "E:\\...\\workspace\\new-project",
    environment: { type: "local" }
  }
})

Environment

• OS: Windows 11
• Shell: PowerShell
• Workspace is under OneDrive
• Codex App used as primary UI
• Codex CLI also available
• New project directories are created dynamically by an inbox/workbench automation

Additional note

This is not just a UI preference. It affects whether automated project handoff can be made reliable, auditable, and visible to the user. Current behavior forces a tradeoff between correct cwd and App visibility.