Memories enabled but no stage-1 outputs generated because imported threads keep has_user_event=0

[ucalyptus]

Summary

With features.memories = true, Codex appears to have session/thread data available, but the memory startup pipeline never produces any stage-1 outputs or filesystem memory artifacts.

In the affected setup:

• memory feature is enabled
• thread/session rows exist in the state DB
• first_user_message is populated for CLI threads
• memory_mode is enabled
• but has_user_event remains 0 for all inspected threads

As a result, no threads appear eligible for memory extraction, and the memory pipeline never produces outputs.

Environment

• Codex CLI version: 0.115.0
• Platform: macOS arm64
• Session source: primarily cli

Observed behavior

Config

~/.codex/config.toml contains:

[features]
memories = true

DB state

The local state DB contains thread records, but memory artifacts are not being generated:

• stage1_outputs count = 0
• jobs count = 0
• ~/.codex/memories/ remains empty

The threads table shows:

• source = 'cli'
• memory_mode = 'enabled'
• first_user_message is populated
• has_user_event = 0

Example query pattern:

select id, source, has_user_event, archived, memory_mode, first_user_message
from threads
order by updated_at desc
limit 10;

In the affected case, first_user_message is populated, but has_user_event is still 0 for all inspected CLI threads.

This also means there are zero eligible rows for a query like:

select count(*)
from threads
where source='cli'
  and has_user_event=1
  and archived=0
  and memory_mode='enabled';

which returns:

0

Why this looks wrong

The thread records clearly have user-originated content (first_user_message is non-empty), but they do not seem to be marked as having a user event. If memory startup eligibility depends on has_user_event, this would prevent stage-1 extraction from ever running on otherwise valid threads.

What I tried

• confirmed features.memories = true
• started fresh non-ephemeral root sessions
• confirmed threads are present in the DB
• confirmed memory mode is enabled on those threads
• observed no jobs rows and no stage1_outputs

Expected behavior

If a non-ephemeral root CLI session has a real user prompt and memory_mode='enabled', I would expect it to become eligible for the startup memory pipeline and eventually produce stage-1 outputs and memory artifacts.

Actual behavior

The memory pipeline appears inert because threads with real user prompts still have has_user_event = 0, leaving no eligible threads and no generated memory outputs.

Possible root cause

A thread import / rollout backfill / session persistence path may be failing to set threads.has_user_event = 1 for CLI sessions, even when first_user_message is present.