Threads generated by automations have been automatically archived

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

• #14656

Powered by Codex Action

THIS IS NOT MY ISSUE YOU CLOSED MY OTHER AS A DUPLICATE OF THIS

OPENAI IS NOT LISTENING TO CUSTOMERS - THIS IS A SYMPTOM OF AN ISSUE, YOUR AUTOMATIONS ARE BROKEN NOW BY DESIGN AND ARE COVERING IT UP

https://github.com/openai/codex/issues/15875

Keep closing my related tickets. It's fine, I canceled, I wanted this to work but you're actively working hard to break the app.

https://github.com/openai/codex/issues/15878

Potential duplicates detected. Please review them and close your issue if it is a duplicate. * Archived automation runs remain unread in Previous runs, but are not discoverable as threads or inbox items #14656 _Powered by Codex Action_

GITHUB IS BROKEN THIS AUTOMATION IS BROKEN

I'M CANCELING MY SUBSCRIPTION TO OPENAI

I had the same problem. In my case, it was caused after i cleaned up some branches in my local repository. I removed my local master branch and since the automations always start a worktree from that branch, it failed to create it.

They'll just close it. CODEX is now getting worse than it was when I filed these. Company closes valid defects because they don't like users are upset with them. Company is going to fold.

I’m seeing the same class of issue on macOS with newer builds, with one extra signal: the affected automation runs had already produced inbox/report items before being auto-archived.

Environment:

• Codex Desktop: 26.429.20946 (build 2312)
• app-server reported in logs: 0.128.0-alpha.1
• macOS, local project automations
• automation definitions remain ACTIVE and continue to schedule

Observed:

• Several automation runs completed and created inbox items.
• ~/.codex/sqlite/codex-dev.db shows automation_runs.status = ARCHIVED, archived_reason = auto, and non-empty inbox_title / inbox_summary for the affected runs.
• ~/.codex/state_5.sqlite has matching archived thread rows.
• The runs are visible under Archived chats.

Relevant Desktop log excerpt:

2026-05-01T16:01:48.543Z info [electron-message-handler] [automation-run-cleanup] archiving pending automation runs
2026-05-01T16:01:49.052Z info [AppServerConnection] ... method=thread/archive ... conversationId=019de129-de53-7a53-8ffa-1858deafc2a4
2026-05-01T16:01:49.075Z info [AppServerConnection] ... method=thread/archive ... conversationId=019de152-9d4d-7dd2-ab90-9f096f02db27

This differs from cases where the automation produced no output: here Codex had already created reportable inbox items, but the startup/cleanup path still archived the runs automatically.

I hit the same issue again on a newer macOS Codex Desktop build, specifically after using the in-app update flow.

Environment:

• Codex Desktop: 26.506.31421 (bundle version 2620)
• app/runtime recorded on the thread: 0.129.0-alpha.15
• macOS: 26.3.1 arm64
• Local project automation, execution_environment = worktree

What happened:

1. A scheduled automation ran at 2026-05-09 09:00 Europe/Lisbon and created a new chat/run titled Обзор почты за день.
2. The new automation-created chat appeared in All chats with a blue/new indicator.
3. Before opening it, I clicked the blue in-app Update button for Codex.
4. Codex updated/restarted.
5. After restart, that newly-created automation chat disappeared from All chats and showed as archived in Automations -> Previous runs.

Local evidence for the affected run:

• thread id: 019e0bc0-73c8-70f1-acf8-ab02ecb20398
• state_5.sqlite.threads originally had archived = 1, archived_at = 1778321546 (2026-05-09 10:12:26 UTC), and rollout_path under ~/.codex/archived_sessions/
• ~/.codex/sqlite/codex-dev.db.automation_runs still has:
• status = ARCHIVED
• archived_reason = auto
• created_at = 2026-05-09 08:00:22 UTC
• updated_at = 2026-05-09 10:12:26 UTC
• non-empty inbox_title / inbox_summary
• The run had completed and created inbox items before it was auto-archived.

Relevant desktop log lines:

2026-05-09T08:01:39.520Z info [electron-message-handler] [Directives] creating inbox items conversationId=019e0bc0-73c8-70f1-acf8-ab02ecb20398 itemCount=1 turnId=019e0bc0-7c54-7450-8c8c-c5acba92ae7b
2026-05-09T08:01:39.527Z info [electron-message-handler] [Directives] creating inbox items conversationId=019e0bc0-73c8-70f1-acf8-ab02ecb20398 itemCount=1 turnId=019e0bc0-7c54-7450-8c8c-c5acba92ae7b
2026-05-09T10:12:24.907Z info [electron-message-handler] [automation-run-cleanup] archiving pending automation runs
2026-05-09T10:12:25.256Z info [electron-message-handler] [automation-run-cleanup] archiving pending automation runs
2026-05-09T10:12:26.243Z info [AppServerConnection] response_routed broadcastFallback=false conversationId=019e0bc0-73c8-70f1-acf8-ab02ecb20398 durationMs=6 errorCode=null hadInternalHandler=false hadPending=true method=thread/archive originWebcontentsId=1 requestId=8c37a9b5-ac10-4904-8cc9-a35292c9862c targetDestroyed=false

Manual recovery confirmed the symptom: moving the rollout JSONL from ~/.codex/archived_sessions/ back to ~/.codex/sessions/2026/05/09/ and setting state_5.sqlite.threads.archived = 0, archived_at = NULL made the chat reappear in All chats.

This looks like the startup/update cleanup path is treating a completed automation run with generated inbox items as a pending run and auto-archiving it after restart/update.

I hit the same issue on a newer Codex Desktop build, with details redacted for privacy. This instance may add two useful signals beyond the earlier reports: one cleanup archived multiple automation-created project threads at once, and manual unarchive later rewrote the automation run rows to ACCEPTED, so the current DB state no longer preserves the pre-cleanup status.

Environment:

• Codex Desktop: 26.513.20950 (bundle version 2816)
• Platform: macOS 26.2 arm64
• Local project automation creating recurring project threads

What happened:

After quitting/reopening Codex while testing the new remote connection / update flow, three automation-generated project threads disappeared from the project UI. They were later found under archived threads and could be restored with the app's manual unarchive flow.

The affected runs were from three consecutive days:

2026-05-13  <redacted-conversation-id-1>
2026-05-14  <redacted-conversation-id-2>
2026-05-15  <redacted-conversation-id-3>

Local output files for the completed earlier runs still existed, so this was not local output loss. The project UI threads were hidden because the underlying conversations had been archived.

Relevant log evidence, with conversation ids redacted:

The completed earlier runs had already created inbox/report items:

2026-05-13T03:21:00.334Z info [electron-message-handler] [Directives] creating inbox items conversationId=<redacted-conversation-id-1> itemCount=1 turnId=<redacted-turn-id-1>
2026-05-14T00:55:24.069Z info [electron-message-handler] [Directives] creating inbox items conversationId=<redacted-conversation-id-2> itemCount=1 turnId=<redacted-turn-id-2>

On reopen/startup, Codex ran automation cleanup:

2026-05-15T01:16:31.196Z info [electron-message-handler] [automation-run-cleanup] archiving pending automation runs
2026-05-15T01:16:31.304Z info [electron-message-handler] [automation-run-cleanup] archiving pending automation runs

Immediately after that cleanup, the app archived all three conversations:

2026-05-15T01:16:31.437Z info [AppServerConnection] ... method=thread/archive ... conversationId=<redacted-conversation-id-1>
2026-05-15T01:16:31.446Z info [AppServerConnection] ... method=thread/archive ... conversationId=<redacted-conversation-id-2>
2026-05-15T01:16:31.453Z info [AppServerConnection] ... method=thread/archive ... conversationId=<redacted-conversation-id-3>

For the interrupted current-day run, the preceding resume log showed it was still in progress:

2026-05-15T01:15:38.347Z info [electron-message-handler] maybe_resume_success conversationId=<redacted-conversation-id-3> latestTurnStatus=inProgress markedStreaming=true turnCount=1

After manually unarchiving the three threads through the app UI, automation_runs.status for those rows became ACCEPTED, with updated_at matching the manual unarchive time. The three affected rows also retained non-empty archived message payloads, unlike earlier accepted runs that were not caught by this cleanup:

created              updated              run                status    inbox_title        archived_user_len  archived_assistant_len
2026-05-15 08:30:43  2026-05-15 09:38:55  <redacted-run-3>   ACCEPTED  <redacted>         nonzero            nonzero
2026-05-14 08:31:35  2026-05-15 09:38:54  <redacted-run-2>   ACCEPTED  <redacted>         nonzero            nonzero
2026-05-13 08:31:14  2026-05-15 09:38:49  <redacted-run-1>   ACCEPTED  <redacted>         nonzero            nonzero
2026-05-12 08:42:38  2026-05-12 10:06:53  <earlier-run>     ACCEPTED  <redacted>         0                  0
2026-05-11 08:34:50  2026-05-11 15:07:04  <earlier-run>     ACCEPTED  <redacted>         0                  0

So in this case the current ACCEPTED status is not evidence that these rows were accepted before cleanup; it appears to be a side effect of the later manual unarchive path.

Code-path clue from the packaged app:

The cleanup path appears to call list-pending-automation-run-threads, whose query selects only pending statuses:

SELECT thread_id as threadId
FROM automation_runs
WHERE status IN ('IN_PROGRESS', 'PENDING_REVIEW')
  AND EXISTS (
    SELECT 1
    FROM automations
    WHERE automations.id = automation_runs.automation_id
  )

The inbox update path appears to move completed runs from IN_PROGRESS to PENDING_REVIEW when inbox/report data is written:

UPDATE automation_runs
SET inbox_title = ?,
    inbox_summary = ?,
    status = CASE WHEN status = 'IN_PROGRESS' THEN 'PENDING_REVIEW' ELSE status END,
    updated_at = ?
WHERE thread_id = ?

And the unarchive path appears to turn archived automation runs into ACCEPTED:

UPDATE automation_runs
SET status = ?,
    read_at = COALESCE(read_at, ?),
    updated_at = ?,
    archived_reason = NULL
WHERE thread_id = ? AND status = ?
-- bound status values: ACCEPTED, ARCHIVED

This matches the observed behavior:

1. A completed automation run can have generated inbox/report output but remain in PENDING_REVIEW.
2. Startup/update cleanup treats pending automation runs as cleanup targets.
3. If those runs correspond to local project conversations, cleanup calls thread/archive, hiding the project threads.
4. Manual unarchive restores visibility but rewrites the automation run row to ACCEPTED, obscuring the original pre-cleanup status.

Expected behavior:

Completed automation-created project threads with generated inbox/report items should not be archived from the project UI by startup/update cleanup simply because their automation run status is still PENDING_REVIEW. At minimum, cleanup should avoid thread/archive for visible project conversations unless there is a stronger stale-run condition or explicit user action.

I hit this same class of issue on a current macOS Codex Desktop build, with local evidence from the manual unarchive path.

Environment:

• Codex Desktop: 26.519.31651 (CFBundleVersion 3017)
• Platform: macOS
• Local automation execution environment: worktree
• Automation ID: skill-progression-map
• Thread ID: 019e4d69-9d47-71b1-a5d6-3864d98b97f2

Observed:

1. The scheduled automation ran and produced output/inbox data.
2. After logging out and logging back in, the run appeared archived in the automation previous-runs UI.
3. I manually unarchived it through the app UI.
4. After manual unarchive, local state shows the thread restored:

state_5.sqlite.threads:
  id = 019e4d69-9d47-71b1-a5d6-3864d98b97f2
  archived = 0
  archived_at = NULL
  rollout_path = ~/.codex/sessions/2026/05/22/rollout-2026-05-22T10-00-27-019e4d69-9d47-71b1-a5d6-3864d98b97f2.jsonl
  cwd = ~/.codex/worktrees/d738/Development

The corresponding automation run row now shows:

~/.codex/sqlite/codex-dev.db automation_runs:
  automation_id = skill-progression-map
  status = ACCEPTED
  read_at = 1779433099784
  created_at = 1779415226408  # 2026-05-22T02:00:26Z
  updated_at = 1779434143222  # 2026-05-22T07:15:43Z
  inbox_title = Next skill progression map
  inbox_summary = Prioritize stale-design checks and PR hygiene next
  archived_user_message = non-empty
  archived_assistant_message = non-empty
  archived_reason = NULL

This lines up with the earlier comments here: manual unarchive appears to recover the visible thread and rewrite the automation run into ACCEPTED, so the current DB state no longer proves what the pre-cleanup status was.

Expected behavior: a completed automation run with generated inbox/report output should remain visible in previous runs across logout/login, or at least should not be moved to archived automatically by startup/login cleanup.