Codex sessions: new ~/.codex/sessions files are not picked up and active process mapping falls back to latest session

Summary

I am running codbash on a Linux VPS and viewing it from Windows through an SSH tunnel. Codex session files are being written under ~/.codex/sessions, but fresh Codex sessions do not reliably appear in /api/sessions, and the Running/Active view maps multiple live Codex processes to the same session via fallback-latest.

This looks like two related issues in the Codex integration:

1. The sessions cache invalidation appears to watch Claude paths, but not Codex paths.
2. Active Codex process detection depends on ps + lsof + cwd-match; on my host the lsof call returns an unrelated cwd entry unless -a is used, so process-to-session mapping fails and falls back to the latest Codex session.

Environment

• codbash version: 7.4.0
• OS: Linux VPS
• Node: v22.12.0
• Codex CLI: 0.129.0
• codbash command: codbash run --port=3847 --no-browser
• Browser access: Windows -> SSH local forward -> VPS 127.0.0.1:3847

What I observed

A fresh Codex session file exists on disk, for example:

~/.codex/sessions/2026/05/11/rollout-2026-05-11T11-29-03-<session-id>.jsonl

The file starts with session_meta and includes a valid payload.cwd:

{"type":"session_meta","payload":{"id":"<session-id>","cwd":"/home/devuser/project","originator":"codex_cli_rs","cli_version":"0.129.0"}}

However, /api/sessions did not show this fresh session while the long-running codbash server was up. Restarting/rescanning appears to be required.

At the same time /api/active did detect live Codex processes, but all of them were mapped to the same session with _sessionSource: "fallback-latest", for example:

{
  "kind": "codex",
  "entrypoint": "codex",
  "status": "waiting",
  "sessionId": "<same-old-session-id>",
  "cwd": "/proc/1/cwd (readlink: Permission denied)",
  "_sessionSource": "fallback-latest"
}

Likely cause 1: cache invalidation does not watch Codex files

In src/data.js, loadSessions() uses a hot cache and _sessionsNeedRescan() checks HISTORY_FILE / PROJECTS_DIR, which are Claude paths:

• ~/.claude/history.jsonl
• ~/.claude/projects

But Codex sessions are loaded from:

• ~/.codex/history.jsonl
• ~/.codex/session_index.jsonl
• ~/.codex/sessions/**/*.jsonl

So a new Codex JSONL file can be written without invalidating the cached session list.

Likely cause 2: lsof needs -a for cwd lookup

In getActiveSessions(), cwd lookup is currently done with a command equivalent to:

lsof -d cwd -p <pid> -Fn

On my host this returns cwd entries outside the requested PID, so the first parsed n... line may be unrelated, e.g. /proc/1/cwd (readlink: Permission denied).

This breaks the later cwd + tool session match and causes fallback to the latest Codex session.

The command works correctly for the specific PID when using -a:

lsof -a -p <pid> -d cwd -Fn

Alternatively, on Linux the implementation could use:

readlink /proc/<pid>/cwd

Expected behavior

• New Codex session files under ~/.codex/sessions/**/*.jsonl should appear in /api/sessions without restarting codbash.
• /api/active should map each live Codex process to the correct Codex session when possible.
• If exact mapping is not possible, it should avoid confidently assigning the wrong latest session to every process.

Suggested fixes

1. Extend cache invalidation to include Codex paths:

   • ~/.codex/history.jsonl mtime/size
   • ~/.codex/session_index.jsonl mtime/size
   • ~/.codex/sessions recursive or shallow date-dir mtimes

2. Fix cwd lookup for active processes:

   • use lsof -a -p <pid> -d cwd -Fn, or
   • prefer /proc/<pid>/cwd on Linux and fall back to lsof.

3. Improve Codex active mapping:

   • prefer sessions whose project equals the real process cwd;
   • if multiple sessions match the same cwd, choose the most recently modified Codex JSONL file;
   • if no confident match exists, return sessionId: "" or _sessionSource: "unmatched" instead of fallback-latest, so the UI does not show a misleading active session.

Thanks for the project. The dashboard is very useful; this issue mainly affects long-running codbash servers and multiple concurrent Codex sessions.