SessionStart context is duplicated when editing a message or forking a thread

I traced this against current main (8e649e3afa5cdddfb09a1b85a090b94775045d9b). The duplication mechanism is explicit in the current lifecycle:

1. Session::new() maps InitialHistory::Forked(_) to SessionStartSource::Startup.
2. It records the inherited fork history first.
3. It then queues that Startup SessionStart source.
4. run_pending_session_start_hooks() runs the hook and records its returned context as new developer messages.

So a fork inherits the parent's SessionStart context and then runs a second startup hook after the copy.

There is an important constraint on the possible fix: hook-injected context currently has no persisted provenance that identifies which hook event produced a developer message. HookAdditionalContext is converted to an ordinary developer ResponseItem, and ResponseItemEnvelope::CodexHarnessMetadata currently only tracks client_authored. That means a fork cannot safely remove 'the inherited SessionStart context' without either adding provenance or relying on content/order heuristics. Text-based deduplication would also conflate SessionStart output with developer context produced by other hook types.

Adding a fork value to SessionStartSource is useful and compatible with the reporter's stated use case: a handler matching startup would no longer run on a fork, and fork-aware handlers could opt into fork. However it does not by itself guarantee one effective copy for match-all SessionStart handlers (matcher: None / *), because those handlers match every source and would still inject another context copy. So I don't think changing only Startup -> Fork is a complete fix for the issue title.

The two complete semantics I see are:

• treat a history fork as inheriting SessionStart state and do not rerun SessionStart on that fork; or
• add persisted hook-context provenance, remove/replace inherited SessionStart-produced context, then run a new fork SessionStart hook.

The second is the cleaner lifecycle model if Codex wants Claude-style source: fork, but it is a wider persistence/history change. I did not submit a heuristic patch because the current data model cannot distinguish SessionStart developer context from other hook-injected developer context safely. The immediate minimal API improvement would be a fork source, but that should not be described as universal deduplication unless match-all handler behavior is intentionally changed too.

---

Update — minimal source: fork patch validated and published

I implemented the narrow API/lifecycle improvement above from exact upstream base c9b19deb09c1841ce7acc33ddb96276030936a29:

• branch: https://github.com/charle-z/codex/tree/fix/39951-session-start-fork-source-v3
• commit: 060f953f596d7ec818e459cd7256be860fad73fd
• compare: https://github.com/charle-z/codex/compare/c9b19deb09c1841ce7acc33ddb96276030936a29...fix/39951-session-start-fork-source-v3
• isolated validation run: https://github.com/charle-z/codex/actions/runs/32642571997

The source branch is one commit ahead / zero behind that exact base and changes only five intended files. The patch:

• adds SessionStartSource::Fork / schema value "fork";
• maps InitialHistory::Forked(_) to Fork instead of Startup;
• adds a real thread-fork regression asserting the hook sequence is ["startup", "fork"];
• regenerates the checked-in SessionStart command schema.

The isolated validation run completed successfully. It regenerated/checked the schema, ran the fork E2E regression, ran the complete codex-hooks test crate, ran Rust lint/format gates, rejected unexpected source changes, reran the focal regressions after lint, verified the exact five-file diff, and only then published the source branch. The validation-only PR in my fork was closed without merge after the run.

I also attempted to open the upstream PR, but GitHub returned 403 Resource not accessible by integration for the cross-fork PR creation path. So the branch + SHA above are the submit-ready artifact and evidence.

Scope caveat remains: this patch provides an explicit fork source and fixes startup-only handlers rerunning on forks. It intentionally does not claim universal context deduplication for match-all SessionStart handlers; that still needs the broader lifecycle/provenance decision described above.

Follow-up with the final patch artifact and current-main revalidation (without repeating the lifecycle trace above):

• Source branch: charle-z/codex:fix/39951-session-start-fork-source-v3
• Final source SHA: 060f953f596d7ec818e459cd7256be860fad73fd (fix(core): distinguish fork session start hooks)
• Current upstream main checked: e21bc763a72adb982522032ce1be725b691dc342

The final patch adds SessionStartSource::Fork end-to-end: InitialHistory::Forked(_) queues Fork, matcher input / hook stdin serialize it as "fork", and both the source schema and committed generated schema enumerate fork. The real fork_thread integration test asserts the observed SessionStart sequence is exactly ["startup", "fork"] for parent + fork.

The isolated v3 validation was green for schema regeneration/fixture contract, the real fork_thread E2E, codex-hooks, formatting/lint/fix, and exact diff auditing. I also reapplied the final commit cleanly on the current upstream SHA above. Upstream has advanced five commits since the patch parent (c9b19deb09c1841ce7acc33ddb96276030936a29), but none modifies the five files in this patch; the only recent fork-history-related change I found (#40266) preserves content annotations for spawned-agent history and does not replace this SessionStart lifecycle fix.

Scope note: this patch deliberately does not delete or deduplicate inherited hook context. A generic SessionStart handler that matches all sources can still choose to run on a fork and inject the same text again. The fix supplies the missing fork lifecycle semantic so hook configuration can distinguish startup vs fork; there still is not event-specific persisted provenance that would make selective inherited-SessionStart cleanup safe.

The upstream cross-fork PR path remains blocked for this contributor, so the SHA above is the reviewable source artifact.