Make projects harness-specific

[jlewi]

Problem

Codex projects are currently shared across both Codex harness runtimes, but the meaning of some project fields is runtime-specific.

In particular, cwd is meaningful for the proxy/backend Codex runtime because the app-server can resolve and use a filesystem working directory. For the browser-hosted codex-wasm runtime, a filesystem cwd like . or /workspace does not necessarily make sense and may be invalid on the browser platform.

This creates a schema mismatch:

• projects are global
• runtimes are different
• some project fields are only valid for some runtimes

The recent cwd fixes addressed the immediate browser failure by omitting cwd for wasm requests, but the underlying model is still mixing shared project configuration with runtime-specific semantics.

Why projects are agent runtime specific

A project is effectively a bundle of defaults used to initialize or resume agent threads. Those defaults are interpreted by the active agent runtime.

That means projects are not purely UI labels. They carry runtime-facing configuration such as:

• working directory semantics
• model defaults
• sandbox policy
• approval policy
• writable roots and other execution context

Because the runtime determines how those fields are interpreted, projects are at least partially runtime-specific.

Open questions

• For the browser runtime, what should replace cwd, or how should we define it so it has a meaningful browser-native interpretation?
• What do projects mean for the non-Codex harnesses?
• How should projects show up in the UI?
• Projects already include model, sandbox, approval, and personality, but some of those controls also appear elsewhere in the ChatKit panel. Should the UI expose the other project knobs directly as dropdowns or editors?

Proposed direction

• Split project configuration into shared fields and runtime-specific fields.
• Make cwd runtime-specific rather than universally required.
• Define a browser-appropriate project/workspace identity for codex-wasm.
• Decide whether projects should be explicitly tied to a harness or transport in the data model and UI.