codex app-server can pollute subsequent TUI session metadata (wrong cwd/source/originator)

[szrenwei]

Summary

After starting codex app-server, subsequent Codex TUI sessions launched from a project directory were recorded with incorrect session metadata.

The sessions were started from a CLI/TUI workflow in:

/data00/home/<user>/Work/team-docs

But multiple session records were written as if they came from Desktop / VS Code, and in the wrong working directory:

cwd=/data00/home/<user>
originator=Codex Desktop
source=vscode

The expected metadata should have been:

cwd=/data00/home/<user>/Work/team-docs
originator=codex-tui
source=cli

Environment

• OS: Linux 5.4.0 x86_64
• Affected session metadata was created with codex-cli 0.130.0
• Current local CLI after update: codex-cli 0.131.0
• Storage inspected:
  • ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl
  • ~/.codex/state_5.sqlite

What happened

I normally launch Codex TUI from the repository directory. A previous normal session had metadata like:

{
  "cwd": "/data00/home/<user>/Work/team-docs",
  "originator": "codex-tui",
  "source": "cli"
}

After starting codex app-server, new sessions created from the same repository were indexed incorrectly.

A backup taken before manual repair showed the canonical DB rows in ~/.codex/state_5.sqlite had the wrong cwd/source for 6 sessions from the same day:

cwd=/data00/home/<user>
source=vscode
thread_source=user

The rollout JSONL session_meta first line also showed wrong metadata for most of those sessions:

cwd=/data00/home/<user>
originator=Codex Desktop
source=vscode
cli_version=0.130.0

One JSONL had already been manually corrected by the time the broader backup was taken, but the SQLite threads table still showed the same wrong cwd/source pattern for all 6 affected session rows.

Expected behavior

Starting codex app-server should not affect metadata for later CLI/TUI sessions.

A TUI session launched from a terminal in a repository should consistently write:

cwd=<actual project cwd>
originator=codex-tui
source=cli

This should be true in both:

• the first session_meta line of the rollout JSONL file
• the corresponding row in ~/.codex/state_5.sqlite.threads

Actual behavior

After codex app-server had been started, later TUI sessions were attributed to Desktop / VS Code and indexed under the parent home directory instead of the active project directory.

This caused repository-based session lookup to fail or return incomplete results, because the affected sessions no longer appeared to belong to the project they were actually launched from.

Impact

Tools and workflows that rely on session metadata break or become misleading:

• listing sessions for the current repository misses affected sessions
• session recall/search by cwd points to the wrong directory
• TUI sessions appear to have been created by Desktop / VS Code
• the JSONL session file and SQLite thread index can disagree during/after partial repair

Manual repair performed

I manually repaired:

• the first-line session_meta payload in affected ~/.codex/sessions/.../rollout-*.jsonl files
• the corresponding cwd and source fields in ~/.codex/state_5.sqlite.threads

After repair, all 6 affected sessions resolved correctly under:

/data00/home/<user>/Work/team-docs

with:

originator=codex-tui
source=cli

logs_2.sqlite still contains historical telemetry strings such as Codex_Desktop / source=vscode, but those appear to be log text rather than the canonical session metadata index.

Related issues

I found a few Desktop/session-history related issues, for example #20864 and #20741, but this report is specifically about codex app-server apparently leaking Desktop/VS Code attribution into later TUI session metadata and the SQLite thread index.

[jshaofa-ui]

openai/codex #23437: App-Server Pollutes TUI Session Metadata

Issue

• URL: codex app-server can pollute subsequent TUI session metadata (wrong cwd/source/originator) #23437
• Type: Bug (CLI, Regression, App-Server)
• Labels: bug, CLI, regression, app-server
• Quote: $1,000–$3,000

Summary

After starting codex app-server, subsequent Codex TUI sessions launched from a project directory were recorded with incorrect session metadata. Sessions were started from a CLI/TUI workflow in /data00/home/<user>/Work/team-docs but multiple session records were written as if they came from Desktop / VS Code, in the wrong working directory (cwd=/data00/home/<user>, originator=Codex Desktop, source=vscode).

Expected: cwd=/data00/home/<user>/Work/team-docs, originator=codex-tui, source=cli.

Root Cause Analysis

1. Session Metadata Pollution

The codex app-server likely maintains global/shared state for session metadata that is not properly isolated between:

• App-server sessions (which may set originator/source from the app-server context)
• CLI/TUI sessions (which should use their own cwd/originator/source)

2. Likely Code Paths

Hypothesis A: Shared Session Store
The app-server and CLI/TUI share a session metadata store (likely in-memory or a file). When the app-server starts, it writes its own metadata (cwd, originator, source) to the shared store, and subsequent CLI sessions read from this store instead of computing their own.

Hypothesis B: Environment Variable Inheritance
The app-server may set environment variables (CODEX_ORIGINATOR, CODEX_SOURCE, CODEX_CWD) that are inherited by child processes or persisted to a config file that CLI sessions read.

Hypothesis C: State File Not Reset
A state file (e.g., ~/.codex/session-state.json or similar) is written by the app-server with its metadata and not cleared/overwritten when CLI sessions start.

3. Regression Nature

The issue is labeled as regression, meaning this worked correctly in a previous version. The regression was likely introduced when:

• App-server support was added or modified
• Session metadata handling was refactored
• Shared state between app-server and CLI was introduced

Proposed Fix

Fix 1: Session Metadata Isolation

Ensure each session computes its own metadata independently:

// Pseudocode
function computeSessionMetadata(): SessionMetadata {
  return {
    cwd: process.cwd(),           // Always use current working directory
    originator: detectOriginator(), // Detect from actual launch context
    source: detectSource(),        // Detect from actual launch source
    sessionId: generateId(),
    timestamp: Date.now(),
  };
}

function detectOriginator(): string {
  // Check launch context, not shared state
  if (process.env.CODEX_ORIGINATOR) return process.env.CODEX_ORIGINATOR;
  if (isTUI()) return 'codex-tui';
  if (isVSCode()) return 'vscode';
  if (isDesktop()) return 'Codex Desktop';
  return 'cli';
}

function detectSource(): string {
  if (process.env.CODEX_SOURCE) return process.env.CODEX_SOURCE;
  if (isVSCodeExtension()) return 'vscode';
  if (isAppServer()) return 'app-server';
  return 'cli';
}

Fix 2: App-Server State Separation

Separate app-server state from CLI/TUI state:

// App-server should use its own state namespace
const APP_SERVER_STATE_KEY = 'app-server:session-state';
const CLI_STATE_KEY = 'cli:session-state';

function getSessionState(key: string): SessionState {
  // Never read app-server state for CLI sessions
  if (key.startsWith('app-server:') && !isAppServer()) {
    return null; // Force fresh state computation
  }
  return loadState(key);
}

Fix 3: Metadata Override Prevention

Prevent app-server from overwriting CLI session metadata:

function setSessionMetadata(metadata: Partial<SessionMetadata>): void {
  const currentSession = getCurrentSession();
  
  // Only allow metadata updates from the session's own context
  if (metadata.originator && currentSession.originator !== metadata.originator) {
    if (currentSession.source === 'cli' && metadata.source === 'app-server') {
      logger.warn('Blocking app-server metadata override on CLI session');
      return; // Reject the override
    }
  }
  
  // Apply metadata update
  Object.assign(currentSession.metadata, metadata);
}

Implementation Details

Files to Modify

1. Session metadata computation — Ensure cwd/originator/source are computed per-session
2. App-server state management — Separate app-server state from CLI state
3. State file handling — Use separate state files or namespaces for app-server vs CLI

Configuration

No new configuration needed — this is a bug fix that should be transparent to users.

Test Plan

Unit Tests

1. computeSessionMetadata() returns correct values for CLI sessions
2. App-server state does not leak into CLI session metadata
3. detectOriginator() correctly identifies launch context
4. Metadata override prevention blocks cross-context updates

Integration Tests

1. Start app-server, then launch CLI session — CLI session has correct metadata
2. Launch multiple CLI sessions after app-server — all have correct metadata
3. Launch CLI session without app-server — metadata correct (regression)
4. Restart app-server — previous app-server state doesn't affect new CLI sessions

Regression Tests

1. App-server sessions still have correct app-server metadata
2. VS Code extension sessions still have correct VS Code metadata
3. Desktop app sessions still have correct Desktop metadata

Impact Assessment

• Severity: Medium-High — Session metadata corruption affects auditability and debugging
• Affected users: Users who run both app-server and CLI/TUI sessions
• Frequency: Every CLI session launched after app-server
• Estimated value: $1,000–$3,000 (regression bug, app-server area)

[etraut-openai]

This is fixed in 0.133.0

[bsabiston]

This is fixed in 0.133.0

@etraut-openai Not fixed for me in the Codex app.
My About dialog shows Desktop 26.527.31326 (3390), but I do not know what bundled CLI/app-server version that corresponds to. Is there a way in Codex Desktop to confirm that the embedded app-server is actually 0.133.0 or later? My Desktop sidebar/history issue is still reproducible on this Desktop build.

[etraut-openai]

@bsabiston, this bug was specifically about metadata recorded when creating a new thread via the TUI. It sounds like you're using the app.

[bsabiston]

@bsabiston, this bug was specifically about metadata recorded when creating a new thread via the TUI. It sounds like you're using the app.

@etraut-openai I see - sorry. Is there any way to call attention to the problem with the app losing all but the most recent chats in all projects? #20741