Codex Studio

Application-scoped revision context

Codex Studio is a Windows revision workspace for the currently mounted cApp application. It captures the chosen application context, requests structured proposals through the native Codex provider and validates each proposed visual mutation before preview.

It is separate from AI Studio, which routes local Vision/Planning/Execution models, and from Agent, which operates on scoped projects. Codex Studio does not provide a repository picker, a Local AI model manager or a general-purpose coding terminal.

Open it with Ctrl+Shift+C in an installed package containing uk.capp.sidecar.codex-studio. A native provider bridge and a usable local Codex executable are prerequisites; a static/browser preview does not create them.

Connect the provider

Use Start / refresh in the workspace to inspect/start its Codex app-server connection. An optional Codex executable override identifies the local executable used by the native host. When account setup is needed, use Login through that host rather than entering provider credentials into your app's source or public documentation.

Select a model returned by the provider's current model list and an available effort setting. The package's configured default is not a promise that an account has that model. A running app-server, an authenticated account and a completed model turn are three different states.

Before sharing context, use a safe test account and remove sensitive values from the mounted application. Sanitisation limits what is captured; it is not a guarantee that every piece of private text or business data has disappeared. Review the chosen context scope as a disclosure decision.

Choose the smallest useful context

These are context budgets, not new execution permissions. The script inventory is not arbitrary filesystem access. Selecting a larger mode may expose more application source and data and may require more capture/provider work.

In package modes, readable selectors accompany compact references such as selector_014. Proposed references are resolved back to the captured target and validated locally. A selector reference is tied to that capture, not a durable application API or authority to target another document.

First successful revision

1. Open the application route to revise and let its dynamic content settle. Start/refresh the provider and check the selected model.
2. Choose Semantic baseline or UI package. Start with a bounded request, for example: “Improve the hierarchy of this settings form without changing labels, fields or behaviour.”
3. Inspect the context and app-only capture. The turn builds design obligations and streams readable progress while complete focus proposals become available.
4. Review each valid preview. Keep or reject individual focus revisions instead of treating every generated suggestion as one indivisible change.
5. Accept only the selected visual revisions. Check the resulting controls, narrow layout and keyboard interaction in the actual application.

A functionality proposal is not executed code. UI + runtime context may produce inspectable suggestions tied to script references, but the workspace does not automatically apply those suggestions as repository changes.

Preview and saved-state boundaries

A new preview replaces the previous preview snapshot. Rejecting a focus recomputes the selected operation set rather than intentionally stacking old previews indefinitely. Review the remaining visual result after each selection change.

Accepted visual profiles are application-scoped. The persistence and auto-application controls govern their local reuse. Accept is not Compile, Package, Publish or a Git commit. To turn an idea into maintained product source, make and test that change through your normal source workflow and build a new release.

A route or DOM change can invalidate a captured target. Refresh the context before asking for a revision of a different application state; do not reuse old selector references as permanent identifiers.

Authority and use

There is no portable Codex Studio SDK for your product to issue shell commands, change arbitrary files or operate other apps. Use the workspace UI, not private controller globals.

The design turn is intended for structured visual proposals. Unexpected command execution, file changes, web searches or tool calls are rejected by this workflow and can interrupt the turn. They are not an invitation to add a permissive tool grant. The ability to log into a provider is separate from approval to disclose application context or retain a proposal.

The default design-turn setting has no elapsed-time deadline. Setup, transport and individual RPC operations still have their own failure/timeout paths. Use the visible cancellation/interruption control for a turn you no longer need; do not infer that a long-running turn succeeded or automatically retry it as a second request.

Troubleshooting

Test provider startup, a complete review/accept/reject cycle, cancellation and profile behaviour in the target installation. No page example certifies provider availability, account entitlement or native execution.

Configuration reference

These are the selected package's configuration fields. String credential values and installation-specific defaults are never published here. A field's presence does not bypass its runtime policy.