TypeScript SDK: Expand feature coverage — fork, session management, messages, metadata

Problem

The @openai/codex-sdk TypeScript SDK currently exposes a very narrow API surface compared to both the Codex CLI and comparable agent SDKs (e.g., @anthropic-ai/claude-agent-sdk). The SDK is architecturally a thin wrapper around codex exec --experimental-json + JSONL stdin/stdout parsing, which limits its exposed feature set to what codex exec supports.

The CLI itself has richer capabilities (codex fork, codex archive, codex delete, codex plugin, etc.) that are not accessible through the SDK path because they are either TUI-only or not available under codex exec.

Current SDK API

new Codex(options)
  .startThread(options?) → Thread
  .resumeThread(id, options?) → Thread

Thread {
  .run(input, turnOptions?) → Promise<Turn>
  .runStreamed(input, turnOptions?) → Promise<StreamedTurn>
  .id → string | null
}

Requested Features

1. Fork Session

CLI has it: codex fork [SESSION_ID] exists but is TUI-only with no --json flag.
SDK needs: codex.forkThread(threadId, options?) or codex exec fork <id> --json to produce a new thread ID from an existing session. This is critical for CI/CD and multi-agent workflows where you need to branch a conversation.

2. Session Management (list, get info, delete, rename, archive)

The CLI has codex archive, codex delete, codex unarchive, and codex resume --last. The SDK has none of these.
SDK needs: codex.listThreads(), codex.getThreadInfo(threadId), codex.deleteThread(threadId). These allow programmatic session lifecycle management.

3. Get Session Messages

No way to retrieve the message history of a thread without actively running a turn and capturing events.
SDK needs: thread.getMessages() or codex.getThreadMessages(threadId). Claude Agent SDK exposes getSessionMessages() for this exact purpose.

4. System Prompt / Developer Instructions

No first-class support for injecting system prompts or developer instructions.
SDK needs: ThreadOptions.systemPrompt or equivalent. Compare Claude Agent SDK: systemPrompt?: string | string[] | { type: "preset"; preset: "claude_code"; append?: string }.

5. Skills / Plugins

CLI has codex plugin for managing plugins. SDK has no way to enable/disable skills or plugins per thread.
SDK needs: ThreadOptions.skills?: string[] for selective skill enablement, similar to Claude Agent SDK.

6. Built-in Tools Configuration

No way to configure which built-in tools are available (Bash, Read, Write, Edit, WebSearch, etc.).
SDK needs: ThreadOptions.tools?: string[] or ThreadOptions.allowedTools / disallowedTools.

7. Metadata / Labels

No way to attach labels, trace IDs, or custom metadata to threads for observability.
SDK needs: ThreadOptions.metadata?: Record<string, string>.

Why This Matters

Embedding agents into platforms (IDEs, CI/CD, multi-agent systems) requires programmatic control over the full session lifecycle. The current SDK supports the "run a turn" path but lacks the surrounding infrastructure that production integrations need: fork for branching workflows, list/get/delete for session management, message retrieval for history display, and metadata for observability.

The Claude Agent SDK demonstrates what a complete agent SDK looks like — and the gap between it and @openai/codex-sdk is measurable in the number of missing API surface rather than in implementation quality.

Architecture Note

The root cause may be the codex exec boundary. A possible technical direction:

• Add codex exec fork <id> --json as a non-interactive fork command
• Add codex exec list --json for session listing
• Add codex exec info <id> --json for session metadata
• Or expose a higher-level HTTP/stdio API that does not route through the existing exec CLI subcommand

Context

We are building @inori/runtime, an abstraction layer over multiple agent SDKs (Claude + Codex). We have successfully integrated:

• run(), stream() via Codex SDK
• resumeThread() for session continuation
• openSession() via persistent thread handles

The missing features listed above are blocking us from achieving feature parity with our Claude harness, which already supports fork, history, messages, skills, system prompts, and metadata.