Skip to content

Import #779: --ephemeral on task, for runs nothing should come back to - #16

Merged
Edo771977 merged 2 commits into
mainfrom
claude/focused-carson-khonz0
Sep 22, 2026
Merged

Edo771977 merged 2 commits into
mainfrom
claude/focused-carson-khonz0

Conversation

@Edo771977

Copy link
Copy Markdown
Owner

One new PR upstream, and this one is a feature rather than a fix.

354/354, full suite run twice. tsc clean.

What it does

executeTaskRun() hardcoded persistThread: true, so every task created a persistent Codex thread — including disposable, fire-and-forget work, which then filled Codex's Recent list with Codex Companion Task: … entries nobody would ever open. runAppServerTurn already took a per-call persistThread; this wires it to an opt-in flag. Omitting it changes nothing.

What makes it worth taking is that it follows through on the consequences: an ephemeral run carries an ephemeral bit on its job record, so findLatestResumableTaskJob never offers it as a --resume-last candidate, and /codex:status and /codex:result stop printing a codex resume <id> line for a thread that was never persisted.

Resolved on top of the import

  • six union conflicts in codex-companion.mjs, where this fork's task already carries --sandbox, --read-root and --resume-thread that upstream's base does not
  • their refusal covers --resume/--resume-last only. This fork has a third resume form, --resume-thread <id>, and an ephemeral thread is exactly as unresumable by id as by recency — so the check and its message cover it too, with a test of its own
  • tests/runtime.test.mjs was an add/add conflict. Our file is kept whole and their six ephemeral tests appended from their own copy, rather than splicing two versions of one file together — that splice is how a test ends up wearing another test's body
  • the flag is wired through /codex:rescue and its subagent. Without that it would exist only on the CLI: rescue.md enumerates the flags it forwards, so a user typing /codex:rescue --ephemeral … would have had it swallowed into the prompt text, and the README would have promised a flag that the command everyone actually types silently drops

Guide

The README documents the flag where the other routing flags live — what it does, that it is refused with all three resume forms, that an ephemeral run is never a --resume-last candidate, and that the default is unchanged — plus the row in the imports table. rescue.md's argument hint and the subagent's routing rules list it, and a command-contract test asserts both sides of that forwarding.

Sabotage matrix

sabotage which tests fail
--ephemeral ignored (persistThread always true) 3, including "runs without persisting a Codex thread"
the --resume-thread refusal dropped "task --ephemeral rejects --resume-thread"
ephemeral jobs offered to --resume-last again "a completed ephemeral task cannot be picked up by a later --resume-last"

🤖 Generated with Claude Code

https://claude.ai/code/session_01UXfvnjSC72HsM6EEPVt2Tg


Generated by Claude Code

0dimen and others added 2 commits September 22, 2026 20:11
`executeTaskRun` hardcoded `persistThread: true`, so every `task` run
created a persistent Codex thread even for disposable, fire-and-forget
work (e.g. many parallel subtasks from an orchestrating agent), flooding
Codex Recent with `Codex Companion Task: ...` entries with no opt-out.

`runAppServerTurn` already supports a per-call `persistThread` toggle
that maps to the app-server's `ephemeral` thread param, and `codex exec`
already exposes `--ephemeral` at the top level. This wires the same
toggle into `codex-companion.mjs task` as an opt-in `--ephemeral` flag.

- Default behavior is unchanged: omitting the flag persists a thread
  exactly as before, and `--resume`/`--resume-last` are untouched.
- `--ephemeral` is rejected together with `--resume`/`--resume-last`,
  since an ephemeral thread cannot be resumed.
- Job records now carry an `ephemeral` bit so `findLatestResumableTaskJob`
  never offers an ephemeral run as a `--resume-last` candidate, and so
  status/result rendering stops suggesting `codex resume <id>` for a
  thread that was never persisted.

Verified against a real Codex CLI (0.155.1, logged-in ChatGPT account)
against `~/.codex/state_5.sqlite`: a single `--ephemeral` task added 0
rows for its cwd, a plain `task` added 1 (unchanged default), 3 parallel
`--ephemeral` tasks added 0 more, and `--resume-last` still resumed the
persisted thread with context intact.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ack to

executeTaskRun() hardcoded persistThread: true, so every task created a
persistent Codex thread — including disposable, fire-and-forget work, which
then filled Codex's Recent list with "Codex Companion Task: …" entries
nobody would ever open. runAppServerTurn already took a per-call
persistThread; this wires it to an opt-in flag. Omitting it changes
nothing.

The import is careful about the consequences, which is what makes it worth
taking: an ephemeral run carries an `ephemeral` bit on its job record, so
findLatestResumableTaskJob never offers it as a --resume-last candidate,
and status/result stop printing a `codex resume <id>` line for a thread
that was never persisted.

Resolved on top of the import:

- six union conflicts in codex-companion.mjs, where this fork's task
  already carries --sandbox, --read-root and --resume-thread that
  upstream's base does not
- their refusal covers --resume/--resume-last. This fork has a third
  resume form, --resume-thread <id>, and an ephemeral thread is exactly as
  unresumable by id as by recency, so the check and its message cover it
  too, with a test
- tests/runtime.test.mjs was an add/add conflict: our file is kept whole
  and their six ephemeral tests are appended from their own copy, rather
  than splicing two versions of the same file together
- the flag is wired through /codex:rescue and its subagent. Without that it
  would exist only on the CLI, and the README would promise a flag that the
  command everyone actually types silently drops

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UXfvnjSC72HsM6EEPVt2Tg
@Edo771977
Edo771977 merged commit 93a2a47 into main Sep 22, 2026
1 check passed
@Edo771977
Edo771977 deleted the claude/focused-carson-khonz0 branch September 22, 2026 20:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants