Companion/review jobs should not share the user's main Codex Desktop history feed by default

Summary

codex-plugin-cc companion/review jobs currently run codex app-server against the user's normal Codex home (~/.codex). As a result, automated Claude Code review/stop-gate/background task threads are written into the same Codex state DB and recency feed used by Codex Desktop.

For users who use both Codex Desktop and the Claude Code plugin heavily, this can bury human Desktop chats/projects behind large numbers of plugin-generated companion threads.

Observed behavior

On macOS with Codex Desktop + Claude Code + codex-plugin-cc review gate enabled:

• Claude Code stop-review jobs create threads titled like:
  • Codex Companion Task: <task> Run a stop-gate review...
• Those threads are stored in the main ~/.codex/state_5.sqlite.
• Codex Desktop's sidebar/project recency can then be dominated by companion jobs.
• Older human-created Codex Desktop project chats still exist in the DB, but may not appear in the visible recent sidebar because they are pushed out by plugin-generated activity.

Expected behavior

Companion/review/background jobs should not write automation history into the same state/feed used for human Codex Desktop chats unless the user explicitly opts into that.

Proposed fix

Run companion-launched codex app-server processes with a plugin-owned Codex home, for example:

$CLAUDE_PLUGIN_DATA/codex-home/<workspace-hash>

or another stable plugin-owned path.

That isolated home would own:

• state_5.sqlite
• sessions
• logs
• app-server recency/history for companion jobs

It could still reuse authentication safely via one of:

• protocol login, if supported;
• a symlink to the user's existing ~/.codex/auth.json;
• a documented setup flow for the plugin-owned Codex home.

There should also be an escape hatch for users who intentionally want shared state/history, e.g.:

CODEX_COMPANION_SHARE_CODEX_HOME=1

Notes

I have not confirmed this is the full cause of every Codex Desktop sidebar visibility issue. There may also be separate Desktop sidebar pagination/hydration behavior involved.

The specific issue here is narrower: plugin-generated automation threads appear to share the user's primary Codex Desktop state/feed by default, which makes recency-based UI surfaces much noisier and can hide human chats from normal view.

Related issues

This is adjacent to, but not the same as:

• #251, profile/config selection for companion-launched jobs
• #199, client identity/attribution
• #108, companion broker lifecycle/cleanup
• openai/codex#17540, Codex Desktop sidebar/project hydration/recency issues

Start by tracing where companion and review jobs launch codex app-server, then inspect how $CLAUDE_PLUGIN_DATA, ~/.codex, and authentication are handled. Implement plugin-owned Codex homes by default, preserve an explicit shared-home escape hatch, and verify that automation state is separated without breaking authentication.