最近从 Codex 转用 Pi Coding Agent，于是想把原本的 Codex 给卸载掉。但是沙盒相关的功能在系统里拉屎实在不知道该怎么安全的清理…
Codex 拉的屎包括但不限于创建沙盒用户和组，修改 Codex 打开过的文件夹安全权限…
Codex 拉的 （点击了解更多详细信息）看了 GitHub 上有关的 issue，改的还不止项目文件夹，甚至还会修改 AppData 的权限…不知道还有没有其他隐藏的坑。
Windows 的权限管理搞不明白，有没有佬指点一下该怎么安全的清理这一坨东西 
zusorio
bug
windows-os
sandbox
CLI
### What version of Codex CLI is running? codex-cli 0.116.0 ### What subscript…ion do you have? Pro ### Which model were you using? _No response_ ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What terminal emulator and version are you using (if applicable)? _No response_ ### What issue are you seeing? I ran into #12226. I'd like to revert the changes the Codex CLI made to my system during install and cleanly uninstall it. There isn't a way to do this. It seems crazy that the install process makes deep enough changes to my system to break something as core as SSH, and then there's no way to remove it. ### What steps can reproduce the bug? Install Codex CLI with Sandbox on Windows. ### What is the expected behavior? _No response_ ### Additional information _No response_
github.com/openai/codex Codex sandbox installation corrupts ACL on AppData 已打开 03:19PM - 25 Mar 26 UTC
thunderstatic
bug
windows-os
sandbox
### What version of the Codex App are you using (From “About Codex” dialog)? 26….313.5234 ### What subscription do you have? Free ### What platform is your computer? Microsoft Windows NT 10.0.19045.0 x64 ### What issue are you seeing? #### Description After installing Codex on Windows 10 and subsequently enabling/installing its sandbox component, Opera, Opera GX, and Opera Developer fail to launch entirely. The browsers flash a black screen 2–3 times and silently close. The issue appears specifically after the sandbox setup step, not immediately after the initial Codex installation. Chrome (stable) and Brave are unaffected. #### Root Cause Codex creates a local Windows group `CodexSandboxUsers` and local users `CodexSandboxOffline` / `CodexSandboxOnline` during installation, and modifies ACL permissions on `AppData\Local`. This breaks the Chromium sandbox for any browser installed under `AppData\Local` (Opera, Opera GX, Chrome Canary), because the GPU process requires the `ALL APPLICATION PACKAGES (S-1-15-2-1)` permission on that path to launch in sandboxed mode. Browsers installed in `Program Files` (Chrome stable, Brave, Edge) are unaffected because their `AppData\Local` path is not involved in the same way. ### What steps can reproduce the bug? 1. Install Codex on Windows 10 2. Go through the sandbox setup/activation step within Codex 3. Launch Opera, Opera GX, or Opera Developer → browser closes immediately ### What is the expected behavior? The sandbox installation step should not modify ACL permissions on `AppData\Local` in a way that affects other applications, or should at minimum restore them on uninstall/rollback.
github.com/openai/codex Windows sandbox hardening 已打开 07:14PM - 21 May 26 UTC
oxsignal
enhancement
windows-os
sandbox
CLI
app
### What variant of Codex are you using? CLI and Desktop ### What feature woul…d you like to see? One more hardening suggestion for the Windows sandbox: When the workspace/write root is `%USERPROFILE%`, Codex expands it into top-level user-profile children. This can include sensitive locations such as OneDrive, AppData, Documents, Downloads, Desktop, and similar profile directories. Even if recent patches prevent stale capability SIDs from being reused across unrelated workspaces, the filesystem ACL setup can still leave Codex-related ACEs on these profile child directories. In my environment I had to manually clean up stale CodexSandboxUsers / capability SID ACEs from several user-profile paths. I think `%USERPROFILE%` should either be rejected as a workspace write root, or sensitive profile children should be excluded by default. At minimum, locations such as the following should not receive broad writable ACLs: - `%APPDATA%` - `%LOCALAPPDATA%` - `%USERPROFILE%\OneDrive` - `%USERPROFILE%\Documents` - `%USERPROFILE%\Desktop` - `%USERPROFILE%\Downloads` - `%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup` Developer-tool caches that normally live under AppData should be redirected to a Codex-controlled cache/temp directory instead of granting broad AppData write access. I also recommend adding an uninstall/cleanup path for Windows sandbox state. If Codex is uninstalled or the Windows sandbox is reset, it should remove the local Codex sandbox users/groups and clean up Codex-created ACEs from the user profile. Otherwise, stale CodexSandboxUsers / capability SID ACL entries can remain on disk indefinitely after the product is removed. ### Additional information _No response_
3 个帖子 - 3 位参与者