没有人觉得codex APP再Windows上的权限管理很蠢吗？

感觉可以跟微软的Win11坐一桌了。各种BUG。权限错误在codex issues里一搜一大堆

abocha

### What version of the Codex App are you using (From “About Codex” dialog)? …26.506.31421 ### What subscription do you have? ChatGPT Plus ### What platform is your computer? Microsoft Windows NT 10.0.26200.8457 x64 ### What issue are you seeing? Windows 11, Codex Desktop 26.506.31421. Problems: 1. Settings -> Configuration cannot save changes: `Unable to save`. 2. `config.toml` is writable manually from PowerShell. ACLs are fine. 3. Workspace Dependencies diagnose as healthy. 4. Chrome plugin cannot be uninstalled from Codex app: `Failed to uninstall plugin`. 5. Chrome/plugin capability is not exposed in new Codex sessions. 6. JS REPL works. 7. In-app browser/browser use works. 8. Shell can launch `chrome.exe` and read the window title, but this is not the Chrome plugin. Likely broken layer: Desktop app config/plugin state management, not filesystem permissions or workspace dependencies. ### What steps can reproduce the bug? Observed on Windows 11 with Codex Desktop 26.506.31421. 1. Open Codex Desktop Settings -> Configuration. 2. Try to save a settings/configuration change. 3. Observe the UI error: `Unable to save`. 4. From PowerShell, manually edit or write `$CODEX_HOME/config.toml`. 5. Observe that the file is writable manually, so this does not appear to be a basic filesystem permission or ACL problem. 6. Run Workspace Dependencies diagnostics. 7. Observe that Workspace Dependencies diagnose as healthy. 8. Open the Codex app plugin UI and try to uninstall the bundled Chrome plugin. 9. Observe the UI error: `Failed to uninstall plugin`. 10. Start a new Codex session and request `@chrome` / Chrome plugin capability. 11. Observe that the Chrome/plugin capability is not exposed in the new session. 12. In the same environment, verify that JS REPL works. 13. Verify that the in-app browser / browser-use capability works. 14. As a control, use shell/PowerShell to launch `chrome.exe` and read the Chrome window title. This succeeds, but it is OS shell automation, not the Codex Chrome plugin. ### What is the expected behavior? - Settings -> Configuration should save changes successfully when `config.toml` is writable. - If a config write fails, the UI should surface the concrete app-server/config error instead of only `Unable to save`. - The Chrome plugin uninstall action should either uninstall successfully or clearly explain why it cannot. - If the Chrome plugin is installed/enabled, new Codex sessions should expose the Chrome plugin capability. - Workspace Dependencies health should not be implicated when diagnostics report healthy and JS REPL/browser-use are working. ### Additional information This looks related to existing Windows Desktop config/plugin state issues, but this report combines both failure modes on the same current Desktop build: - Settings/config saves fail even though `config.toml` is manually writable. - Plugin state management also fails: Chrome plugin uninstall fails and Chrome capability is not exposed in new sessions. - Other runtime layers appear healthy: Workspace Dependencies, JS REPL, in-app browser/browser-use, and shell process launch all work. Possibly related open issues: - #20538 - #20856 - #21670 - #22114 - #22462

gilbrit

### What issue are you seeing? Codex Desktop Preferences can get stuck showing …an "unable to save" error when changing settings that write to `config.toml`, even after restarting the app. The underlying app-server error in the Desktop logs is `configVersionConflict` from `config/value/write`. In the observed case, one Preferences write succeeded and updated `config.toml`, but follow-up writes from the same UI flow failed because they used a stale config version. ### What steps can reproduce the bug? Observed on Windows with Codex Desktop. 1. Open Codex Desktop Preferences. 2. Change settings that touch `$CODEX_HOME/config.toml`, such as approval/sandbox preferences. 3. Observe that the app shows "unable to save". 4. Inspect `config.toml` and Desktop logs. A successful first write was visible in `config.toml`; for example, Preferences added: ```toml sandbox_mode = "workspace-write" ``` Immediately after that, subsequent `config/value/write` requests failed with `configVersionConflict`. Restarting Codex Desktop did not clear the user-visible inability to change those settings. ### What is the expected behavior? Preferences should save the selected config values without surfacing an error. If multiple config values are written as part of one UI interaction, Desktop should either: - use `config/batch/write`, or - re-read the latest config version and retry when a `configVersionConflict` occurs, or - otherwise serialize writes so later writes use the updated config version from the previous successful write. ### What is the actual behavior? The first `config/value/write` can succeed, then later writes fail with: ```text config_write_error_code=configVersionConflict Configuration was modified since last read. Fetch latest version and retry. ``` The UI reports "unable to save" even though the config file may have been partially updated. ### Logs From Codex Desktop logs, redacted for local paths: ```text 2026-04-30T22:35:39.668Z info [AppServerConnection] response_routed ... errorCode=null ... method=config/value/write ... 2026-04-30T22:35:39.673Z info [AppServerConnection] response_routed ... errorCode=null ... method=config/read ... 2026-04-30T22:35:41.600Z info [AppServerConnection] response_routed ... errorCode=-32600 ... method=config/value/write ... 2026-04-30T22:35:41.603Z error [electron-message-handler] Request failed ... error={"code":-32600,"data":{"config_write_error_code":"configVersionConflict"},"message":"Configuration was modified since last read. Fetch latest version and retry."} ... method=config/value/write ... 2026-04-30T22:35:43.624Z info [AppServerConnection] response_routed ... errorCode=-32600 ... method=config/value/write ... 2026-04-30T22:35:43.627Z error [electron-message-handler] Request failed ... error={"code":-32600,"data":{"config_write_error_code":"configVersionConflict"},"message":"Configuration was modified since last read. Fetch latest version and retry."} ... method=config/value/write ... ``` Earlier attempts showed the same failure pattern: ```text 2026-04-30T22:19:42.395Z error [electron-message-handler] Request failed ... error={"code":-32600,"data":{"config_write_error_code":"configVersionConflict"},"message":"Configuration was modified since last read. Fetch latest version and retry."} ... method=config/value/write ... 2026-04-30T22:19:44.159Z error [electron-message-handler] Request failed ... error={"code":-32600,"data":{"config_write_error_code":"configVersionConflict"},"message":"Configuration was modified since last read. Fetch latest version and retry."} ... method=config/value/write ... ``` ### Environment - Codex Desktop on Windows - App package path showed `OpenAI.Codex_26.429.2026.0_x64__...` - Desktop log client version also showed `26.429.20946` - `$CODEX_HOME/config.toml` parsed successfully as TOML before and after the Preferences write ### Additional context This looks related in shape to #15310's proposed fix option of persisting sandbox preference via `config/batch/write`, but this issue is specifically about Desktop Preferences issuing sequential `config/value/write` calls and not recovering from `configVersionConflict`. Manual edits to `config.toml` work as a temporary workaround, but Preferences still reports "unable to save" for these settings.

6 个帖子 - 5 位参与者

阅读完整话题