[4 of 4] tui: route startup and onboarding config writes through app server by etraut-openai · Pull Request #22916 · openai/codex

etraut-openai · 2026-05-15T22:37:34Z

Why

The remaining local writes happen during startup, onboarding, and prompt bookkeeping. They are less common than interactive settings changes, but they are still real config mutations and should follow the same app-server ownership model instead of reaching around it.

This is [4 of 4] in a stacked series that moves TUI-owned config mutations onto app-server APIs.

What changed

Deferred OSS provider persistence until the app server is available, then wrote it through config/batchWrite.
Moved onboarding project-trust persistence out of the TUI widget and into an app-server-backed config write after the trust decision is made.
Routed startup tooltip counts, warning dismissals, model-migration acknowledgements, and external-config-migration prompt bookkeeping through app-server config writes.

Config keys affected

oss_provider
projects.<project_key>.trust_level
tui.model_availability_nux.<model_slug>
notice.hide_full_access_warning
notice.hide_world_writable_warning
notice.hide_rate_limit_model_nudge
notice.model_migrations.<from_model>
notice.external_config_migration_prompts.home
notice.external_config_migration_prompts.home_last_prompted_at
notice.external_config_migration_prompts.projects.<project_key>
notice.external_config_migration_prompts.project_last_prompted_at.<project_key>

Suggested manual validation

Launch with --oss when no OSS provider is configured, pick a provider manually, and confirm oss_provider is persisted through the app-server path.
Run the trust-directory onboarding flow in embedded app-server mode and confirm the trusted project lands under projects.<project_key>.trust_level.
Exercise one startup bookkeeping flow, such as a model availability NUX tooltip or a model migration acknowledgement, and confirm the corresponding notice key updates remotely.
Dismiss one warning prompt and one external-config-migration prompt, then relaunch and confirm the app-server-owned prompt state suppresses the repeat prompt.

Stack

#22913 [1 of 4] primary settings writes
#22914 [2 of 4] app and skill enablement
#22915 [3 of 4] feature and memory toggles
#22916 [4 of 4] startup and onboarding bookkeeping

## Why The TUI can run against a remote app server, but several high-traffic settings still persisted by editing the local config file. That sends remote sessions' preference writes to the wrong machine and lets local disk state drift from the app-server-owned config. This is **[1 of 4]** in a stacked series that moves TUI-owned config mutations onto app-server APIs. ## What changed - Added a small TUI helper for typed app-server config writes. - Routed primary interactive preference writes through `config/batchWrite`. - Preserved existing profile scoping for settings that already support `profiles.<profile>.*` overrides. ## Config keys affected - `model` - `model_reasoning_effort` - `personality` - `service_tier` - `plan_mode_reasoning_effort` - `approvals_reviewer` - `notice.fast_default_opt_out` - Profile-scoped equivalents under `profiles.<profile>.*` ## Suggested manual validation - Connect the TUI to a remote app server, change `model` and `model_reasoning_effort`, reconnect, and confirm the remote config retained both values while the local `config.toml` did not change. - Change `personality`, `plan_mode_reasoning_effort`, and the explicit auto-review selection, then reconnect and confirm those choices persist through the app server. - Clear the service tier back to default and confirm `service_tier` is cleared while `notice.fast_default_opt_out = true` is persisted remotely. - Repeat one setting change with an active profile and confirm the write lands under `profiles.<profile>.*`. ## Stack 1. [#22913](#22913) `[1 of 4]` primary settings writes 2. [#22914](#22914) `[2 of 4]` app and skill enablement 3. [#22915](#22915) `[3 of 4]` feature and memory toggles 4. [#22916](#22916) `[4 of 4]` startup and onboarding bookkeeping

## Why App and skill toggles are user config mutations too. When the TUI is attached to a remote app server, writing those toggles into the local `config.toml` makes the UI report success without updating the server that actually owns the session. This is **[2 of 4]** in a stacked series that moves TUI-owned config mutations onto app-server APIs. ## What changed - Routed app enable/disable persistence through app-server config batch writes. - Routed skill enable/disable persistence through `skills/config/write`. - Avoided refreshing local config from disk after these writes when the TUI is connected to a remote app server. ## Config keys affected - `apps.<app_id>.enabled` - `apps.<app_id>.disabled_reason` - `[[skills.config]]` entries keyed by `path`, with `enabled = false` used for persisted disables ## Suggested manual validation - Connect the TUI to a remote app server, disable an app, reconnect, and confirm the app remains disabled from remote config rather than local disk state. - Re-enable the same app and confirm both `apps.<app_id>.enabled` and `apps.<app_id>.disabled_reason` are cleared remotely. - Disable a skill in the manage-skills UI and confirm a remote `[[skills.config]]` disable entry appears. - Re-enable that skill and confirm the disable entry is removed and the effective enabled state updates without relying on local config reloads. ## Stack 1. [#22913](#22913) `[1 of 4]` primary settings writes 2. [#22914](#22914) `[2 of 4]` app and skill enablement 3. [#22915](#22915) `[3 of 4]` feature and memory toggles 4. [#22916](#22916) `[4 of 4]` startup and onboarding bookkeeping

…2915) ## Why Experimental feature toggles and memory settings can update several related config values in one interaction. Keeping those writes local in a remote TUI session is especially dangerous because the UI can diverge from the app-server config while also leaving behind partially stale supporting keys. This is **[3 of 4]** in a stacked series that moves TUI-owned config mutations onto app-server APIs. ## What changed - Routed feature flag persistence through app-server batch writes, including the supporting reviewer and permission updates used by guardian approval. - Routed Windows sandbox mode persistence and legacy Windows feature cleanup through app-server writes. - Routed memory settings through app-server batch writes and updated the TUI tests to exercise the embedded app-server path. ## Config keys affected - `features.<feature_key>` - `profiles.<profile>.features.<feature_key>` - `approval_policy` - `sandbox_mode` - `approvals_reviewer` - `windows.sandbox` - `features.experimental_windows_sandbox` - `features.elevated_windows_sandbox` - `features.enable_experimental_windows_sandbox` - Profile-scoped Windows legacy feature variants under `profiles.<profile>.features.*` - `memories.use_memories` - `memories.generate_memories` - Profile-scoped memory variants under `profiles.<profile>.memories.*` ## Suggested manual validation - Connect the TUI to a remote app server, toggle guardian approval on and off, and confirm the remote config updates `features.guardian_approval`, reviewer state, approval policy, and sandbox mode coherently. - Toggle a default-false experimental feature at the root level, disable it again, and confirm the key clears instead of lingering as an unnecessary explicit `false`. - Change memory settings and confirm the remote config updates both memory keys while the running TUI reflects the new state. - On Windows, switch sandbox mode through the TUI and confirm `windows.sandbox` is updated while the legacy Windows feature keys are cleared. ## Stack 1. [#22913](#22913) `[1 of 4]` primary settings writes 2. [#22914](#22914) `[2 of 4]` app and skill enablement 3. [#22915](#22915) `[3 of 4]` feature and memory toggles 4. [#22916](#22916) `[4 of 4]` startup and onboarding bookkeeping

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 91d4b257b2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

…-server-4-startup-bookkeeping # Conflicts: # codex-rs/tui/src/app/config_persistence.rs

## Summary The TUI `/mcp` inventory flow should reflect the app server’s MCP status response. It was also joining those results with the TUI process’s local `config.mcp_servers`, which can diverge once MCP state is owned by a remote app server and cause stale local command, URL, status, or empty-state details to render. This change removes the local config join from the app-server-backed inventory renderer. The TUI now renders directly from the existing `mcpServerStatus/list` payload and treats an empty status response as the empty MCP inventory state. ## Known limitation The existing `mcpServerStatus/list` payload does not include disabled-state or disabled-reason fields. To preserve the current app-server API, this PR does not try to infer that state from client-local config. If remote `/mcp` needs to show disabled/reason details again, that should come from app-server-owned status data in a follow-up. Related to #22914, #22915, and #22916.

## Why The TUI can run against a remote app server, but several high-traffic settings still persisted by editing the local config file. That sends remote sessions' preference writes to the wrong machine and lets local disk state drift from the app-server-owned config. This is **[1 of 4]** in a stacked series that moves TUI-owned config mutations onto app-server APIs. ## What changed - Added a small TUI helper for typed app-server config writes. - Routed primary interactive preference writes through `config/batchWrite`. - Preserved existing profile scoping for settings that already support `profiles.<profile>.*` overrides. ## Config keys affected - `model` - `model_reasoning_effort` - `personality` - `service_tier` - `plan_mode_reasoning_effort` - `approvals_reviewer` - `notice.fast_default_opt_out` - Profile-scoped equivalents under `profiles.<profile>.*` ## Suggested manual validation - Connect the TUI to a remote app server, change `model` and `model_reasoning_effort`, reconnect, and confirm the remote config retained both values while the local `config.toml` did not change. - Change `personality`, `plan_mode_reasoning_effort`, and the explicit auto-review selection, then reconnect and confirm those choices persist through the app server. - Clear the service tier back to default and confirm `service_tier` is cleared while `notice.fast_default_opt_out = true` is persisted remotely. - Repeat one setting change with an active profile and confirm the write lands under `profiles.<profile>.*`. ## Stack 1. [#22913](openai/codex#22913) `[1 of 4]` primary settings writes 2. [#22914](openai/codex#22914) `[2 of 4]` app and skill enablement 3. [#22915](openai/codex#22915) `[3 of 4]` feature and memory toggles 4. [#22916](openai/codex#22916) `[4 of 4]` startup and onboarding bookkeeping

## Why App and skill toggles are user config mutations too. When the TUI is attached to a remote app server, writing those toggles into the local `config.toml` makes the UI report success without updating the server that actually owns the session. This is **[2 of 4]** in a stacked series that moves TUI-owned config mutations onto app-server APIs. ## What changed - Routed app enable/disable persistence through app-server config batch writes. - Routed skill enable/disable persistence through `skills/config/write`. - Avoided refreshing local config from disk after these writes when the TUI is connected to a remote app server. ## Config keys affected - `apps.<app_id>.enabled` - `apps.<app_id>.disabled_reason` - `[[skills.config]]` entries keyed by `path`, with `enabled = false` used for persisted disables ## Suggested manual validation - Connect the TUI to a remote app server, disable an app, reconnect, and confirm the app remains disabled from remote config rather than local disk state. - Re-enable the same app and confirm both `apps.<app_id>.enabled` and `apps.<app_id>.disabled_reason` are cleared remotely. - Disable a skill in the manage-skills UI and confirm a remote `[[skills.config]]` disable entry appears. - Re-enable that skill and confirm the disable entry is removed and the effective enabled state updates without relying on local config reloads. ## Stack 1. [#22913](openai/codex#22913) `[1 of 4]` primary settings writes 2. [#22914](openai/codex#22914) `[2 of 4]` app and skill enablement 3. [#22915](openai/codex#22915) `[3 of 4]` feature and memory toggles 4. [#22916](openai/codex#22916) `[4 of 4]` startup and onboarding bookkeeping

…2915) ## Why Experimental feature toggles and memory settings can update several related config values in one interaction. Keeping those writes local in a remote TUI session is especially dangerous because the UI can diverge from the app-server config while also leaving behind partially stale supporting keys. This is **[3 of 4]** in a stacked series that moves TUI-owned config mutations onto app-server APIs. ## What changed - Routed feature flag persistence through app-server batch writes, including the supporting reviewer and permission updates used by guardian approval. - Routed Windows sandbox mode persistence and legacy Windows feature cleanup through app-server writes. - Routed memory settings through app-server batch writes and updated the TUI tests to exercise the embedded app-server path. ## Config keys affected - `features.<feature_key>` - `profiles.<profile>.features.<feature_key>` - `approval_policy` - `sandbox_mode` - `approvals_reviewer` - `windows.sandbox` - `features.experimental_windows_sandbox` - `features.elevated_windows_sandbox` - `features.enable_experimental_windows_sandbox` - Profile-scoped Windows legacy feature variants under `profiles.<profile>.features.*` - `memories.use_memories` - `memories.generate_memories` - Profile-scoped memory variants under `profiles.<profile>.memories.*` ## Suggested manual validation - Connect the TUI to a remote app server, toggle guardian approval on and off, and confirm the remote config updates `features.guardian_approval`, reviewer state, approval policy, and sandbox mode coherently. - Toggle a default-false experimental feature at the root level, disable it again, and confirm the key clears instead of lingering as an unnecessary explicit `false`. - Change memory settings and confirm the remote config updates both memory keys while the running TUI reflects the new state. - On Windows, switch sandbox mode through the TUI and confirm `windows.sandbox` is updated while the legacy Windows feature keys are cleared. ## Stack 1. [#22913](openai/codex#22913) `[1 of 4]` primary settings writes 2. [#22914](openai/codex#22914) `[2 of 4]` app and skill enablement 3. [#22915](openai/codex#22915) `[3 of 4]` feature and memory toggles 4. [#22916](openai/codex#22916) `[4 of 4]` startup and onboarding bookkeeping

…i#22913) ## Why The TUI can run against a remote app server, but several high-traffic settings still persisted by editing the local config file. That sends remote sessions' preference writes to the wrong machine and lets local disk state drift from the app-server-owned config. This is **[1 of 4]** in a stacked series that moves TUI-owned config mutations onto app-server APIs. ## What changed - Added a small TUI helper for typed app-server config writes. - Routed primary interactive preference writes through `config/batchWrite`. - Preserved existing profile scoping for settings that already support `profiles.<profile>.*` overrides. ## Config keys affected - `model` - `model_reasoning_effort` - `personality` - `service_tier` - `plan_mode_reasoning_effort` - `approvals_reviewer` - `notice.fast_default_opt_out` - Profile-scoped equivalents under `profiles.<profile>.*` ## Suggested manual validation - Connect the TUI to a remote app server, change `model` and `model_reasoning_effort`, reconnect, and confirm the remote config retained both values while the local `config.toml` did not change. - Change `personality`, `plan_mode_reasoning_effort`, and the explicit auto-review selection, then reconnect and confirm those choices persist through the app server. - Clear the service tier back to default and confirm `service_tier` is cleared while `notice.fast_default_opt_out = true` is persisted remotely. - Repeat one setting change with an active profile and confirm the write lands under `profiles.<profile>.*`. ## Stack 1. [openai#22913](openai#22913) `[1 of 4]` primary settings writes 2. [openai#22914](openai#22914) `[2 of 4]` app and skill enablement 3. [openai#22915](openai#22915) `[3 of 4]` feature and memory toggles 4. [openai#22916](openai#22916) `[4 of 4]` startup and onboarding bookkeeping

…ai#22914) ## Why App and skill toggles are user config mutations too. When the TUI is attached to a remote app server, writing those toggles into the local `config.toml` makes the UI report success without updating the server that actually owns the session. This is **[2 of 4]** in a stacked series that moves TUI-owned config mutations onto app-server APIs. ## What changed - Routed app enable/disable persistence through app-server config batch writes. - Routed skill enable/disable persistence through `skills/config/write`. - Avoided refreshing local config from disk after these writes when the TUI is connected to a remote app server. ## Config keys affected - `apps.<app_id>.enabled` - `apps.<app_id>.disabled_reason` - `[[skills.config]]` entries keyed by `path`, with `enabled = false` used for persisted disables ## Suggested manual validation - Connect the TUI to a remote app server, disable an app, reconnect, and confirm the app remains disabled from remote config rather than local disk state. - Re-enable the same app and confirm both `apps.<app_id>.enabled` and `apps.<app_id>.disabled_reason` are cleared remotely. - Disable a skill in the manage-skills UI and confirm a remote `[[skills.config]]` disable entry appears. - Re-enable that skill and confirm the disable entry is removed and the effective enabled state updates without relying on local config reloads. ## Stack 1. [openai#22913](openai#22913) `[1 of 4]` primary settings writes 2. [openai#22914](openai#22914) `[2 of 4]` app and skill enablement 3. [openai#22915](openai#22915) `[3 of 4]` feature and memory toggles 4. [openai#22916](openai#22916) `[4 of 4]` startup and onboarding bookkeeping

…enai#22915) ## Why Experimental feature toggles and memory settings can update several related config values in one interaction. Keeping those writes local in a remote TUI session is especially dangerous because the UI can diverge from the app-server config while also leaving behind partially stale supporting keys. This is **[3 of 4]** in a stacked series that moves TUI-owned config mutations onto app-server APIs. ## What changed - Routed feature flag persistence through app-server batch writes, including the supporting reviewer and permission updates used by guardian approval. - Routed Windows sandbox mode persistence and legacy Windows feature cleanup through app-server writes. - Routed memory settings through app-server batch writes and updated the TUI tests to exercise the embedded app-server path. ## Config keys affected - `features.<feature_key>` - `profiles.<profile>.features.<feature_key>` - `approval_policy` - `sandbox_mode` - `approvals_reviewer` - `windows.sandbox` - `features.experimental_windows_sandbox` - `features.elevated_windows_sandbox` - `features.enable_experimental_windows_sandbox` - Profile-scoped Windows legacy feature variants under `profiles.<profile>.features.*` - `memories.use_memories` - `memories.generate_memories` - Profile-scoped memory variants under `profiles.<profile>.memories.*` ## Suggested manual validation - Connect the TUI to a remote app server, toggle guardian approval on and off, and confirm the remote config updates `features.guardian_approval`, reviewer state, approval policy, and sandbox mode coherently. - Toggle a default-false experimental feature at the root level, disable it again, and confirm the key clears instead of lingering as an unnecessary explicit `false`. - Change memory settings and confirm the remote config updates both memory keys while the running TUI reflects the new state. - On Windows, switch sandbox mode through the TUI and confirm `windows.sandbox` is updated while the legacy Windows feature keys are cleared. ## Stack 1. [openai#22913](openai#22913) `[1 of 4]` primary settings writes 2. [openai#22914](openai#22914) `[2 of 4]` app and skill enablement 3. [openai#22915](openai#22915) `[3 of 4]` feature and memory toggles 4. [openai#22916](openai#22916) `[4 of 4]` startup and onboarding bookkeeping

## Summary The TUI `/mcp` inventory flow should reflect the app server’s MCP status response. It was also joining those results with the TUI process’s local `config.mcp_servers`, which can diverge once MCP state is owned by a remote app server and cause stale local command, URL, status, or empty-state details to render. This change removes the local config join from the app-server-backed inventory renderer. The TUI now renders directly from the existing `mcpServerStatus/list` payload and treats an empty status response as the empty MCP inventory state. ## Known limitation The existing `mcpServerStatus/list` payload does not include disabled-state or disabled-reason fields. To preserve the current app-server API, this PR does not try to infer that state from client-local config. If remote `/mcp` needs to show disabled/reason details again, that should come from app-server-owned status data in a follow-up. Related to openai#22914, openai#22915, and openai#22916.

This was referenced May 15, 2026

[1 of 4] tui: route primary settings writes through app server #22913

Merged

[2 of 4] tui: route app and skill enablement through app server #22914

Merged

[3 of 4] tui: route feature and memory toggles through app server #22915

Merged

etraut-openai marked this pull request as ready for review May 15, 2026 22:40

etraut-openai force-pushed the etraut/tui-config-app-server-4-startup-bookkeeping branch from fb52e01 to 8cac60f Compare May 15, 2026 22:45

etraut-openai force-pushed the etraut/tui-config-app-server-3-feature-toggles branch 2 times, most recently from d8375c8 to d5f9063 Compare May 15, 2026 22:50

etraut-openai force-pushed the etraut/tui-config-app-server-4-startup-bookkeeping branch from 8cac60f to 6ea4edd Compare May 15, 2026 22:50

github-actions Bot mentioned this pull request May 16, 2026

📊 AI CLI 工具社区动态日报 2026-05-16 zx0828/big_model_radar#58

Open

etraut-openai force-pushed the etraut/tui-config-app-server-3-feature-toggles branch from f0e5a0e to 61beab3 Compare May 19, 2026 17:35

etraut-openai mentioned this pull request May 20, 2026

Fix TUI remote config reads #23625

Closed

Base automatically changed from etraut/tui-config-app-server-3-feature-toggles to main May 21, 2026 23:03

tui: persist startup and onboarding config via app server

91d4b25

etraut-openai force-pushed the etraut/tui-config-app-server-4-startup-bookkeeping branch from 2ec355f to 91d4b25 Compare May 21, 2026 23:23

chatgpt-codex-connector Bot reviewed May 21, 2026

View reviewed changes

Comment thread codex-rs/tui/src/lib.rs Outdated

Comment thread codex-rs/tui/src/lib.rs Outdated

etraut-openai added 3 commits May 21, 2026 16:42

tui: simplify permission override submission

405bb09

tui: keep trust onboarding on config write failure

3129971

Merge remote-tracking branch 'origin/main' into etraut/tui-config-app…

52e8395

…-server-4-startup-bookkeeping # Conflicts: # codex-rs/tui/src/app/config_persistence.rs

github-actions Bot mentioned this pull request May 22, 2026

📊 AI CLI 工具社区动态日报 2026-05-22 ivanweng2077/big_model_radar#68

Open

etraut-openai closed this May 23, 2026

This was referenced May 23, 2026

TUI config cleanup: plugin marketplace #24257

Merged

TUI config cleanup: MCP inventory #24265

Merged

TUI config cleanup: plugin mentions #24266

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[4 of 4] tui: route startup and onboarding config writes through app server#22916

[4 of 4] tui: route startup and onboarding config writes through app server#22916
etraut-openai wants to merge 4 commits into
mainfrom
etraut/tui-config-app-server-4-startup-bookkeeping

etraut-openai commented May 15, 2026 •

edited

Loading

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

etraut-openai commented May 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why

What changed

Config keys affected

Suggested manual validation

Stack

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

etraut-openai commented May 15, 2026 •

edited

Loading