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

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

Issue

• URL: https://github.com/openai/codex/issues/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)

This is fixed in 0.133.0

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.

@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, 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? https://github.com/openai/codex/issues/20741