I wanted to open this topic because, after trying to use the Codex App on Windows 11 with a reasonable level of privacy, I ran into a problem that I think fits directly within Sandboxie’s purpose.
My main concern is not so much where Codex can write, but what the commands and tools it launches may be able to read. Codex’s sandbox model mainly restricts writes and network access, while aiming to preserve a level of read access similar to that of the real user. From a privacy perspective, limiting writes to the workspace is not the same as limiting what information those processes can access.
The current Codex sandbox setup on Windows also requires an administrative setup phase to create restricted users, configure rules, and set ACLs. After that, processes run under restricted users and tokens, but additional read permissions are granted in order to preserve the level of read access expected by the design.
That is where I see a contradiction: in order to isolate the application more effectively, I end up accepting an administrative setup phase and explicitly broadening read permissions. In a way, I feel like I am asking the wolf to guard the sheep.
One alternative would be to create a dedicated Windows user manually and use NTFS ACLs to define exactly which directories it is allowed to read. That is possible, but for an average user it means managing users, inherited permissions, ACLs, workspaces, and exceptions. This is exactly where tools like Sandboxie seem increasingly relevant: not only for containing unknown software, but also for compartmentalizing legitimate applications that may process large amounts of local information.
In my tests, trying to install it inside a standard sandbox with:
Add-AppxPackage -Path "ChatGPT.msix"
ends with:
The server endpoint cannot perform the operation.
I do not want to present this as a universal Codex or Sandboxie bug. Installing and activating packaged applications may involve the AppX/WinRT infrastructure and, depending on the application, COM/RPC components and services running outside the sandbox.
In my case, I have not yet identified which exact component is causing the error, so I am not claiming that COM/RPC is necessarily the root cause.
When trying to resolve this type of incompatibility in Sandboxie, it may eventually become necessary to open specific IPC endpoints, COM interfaces, services, or other host resources. The more exceptions that are required to make the application work, the harder it becomes to maintain isolation that is understandable and verifiable.
-“Prevent programs to read files on host system?”
-“New privacy enhanced File/Registry access scheme” (#890)
-“How to start a sandboxed process without access to outside storage?”
-“Compartmentalization for high privacy and security”
-“Can't run programs/installers when privacy mode enabled”
-“Out-of-process COM / WinRT support” (#3850)
I also found discussions about other AI agents such as Cursor Agentic AI, OpenClaw, and Claude Code, so the broader issue of isolating this type of application already seems to be emerging.
However, I have not found a discussion focused specifically on Codex App for Windows, its read-access model, and the difficulties involved in deploying the MSIX application and then running it inside Sandboxie.
My question is:
Has a recommended configuration already been discussed for this type of AI agent using a “deny by default” model, where the processes controlled by the agent can only read the authorized workspace and the minimum system resources required to function?
I think this type of application makes it especially important for Sandboxie to control not only what a program can modify, but also what information on the system it can actually see.
My main concern is not so much where Codex can write, but what the commands and tools it launches may be able to read. Codex’s sandbox model mainly restricts writes and network access, while aiming to preserve a level of read access similar to that of the real user. From a privacy perspective, limiting writes to the workspace is not the same as limiting what information those processes can access.
The current Codex sandbox setup on Windows also requires an administrative setup phase to create restricted users, configure rules, and set ACLs. After that, processes run under restricted users and tokens, but additional read permissions are granted in order to preserve the level of read access expected by the design.
That is where I see a contradiction: in order to isolate the application more effectively, I end up accepting an administrative setup phase and explicitly broadening read permissions. In a way, I feel like I am asking the wolf to guard the sheep.
One alternative would be to create a dedicated Windows user manually and use NTFS ACLs to define exactly which directories it is allowed to read. That is possible, but for an average user it means managing users, inherited permissions, ACLs, workspaces, and exceptions. This is exactly where tools like Sandboxie seem increasingly relevant: not only for containing unknown software, but also for compartmentalizing legitimate applications that may process large amounts of local information.
Problems when trying to run Codex inside Sandboxie
The Windows version of Codex App that I am testing is installed through an MSIX package handled by the Windows AppX deployment infrastructure.In my tests, trying to install it inside a standard sandbox with:
Add-AppxPackage -Path "ChatGPT.msix"
ends with:
The server endpoint cannot perform the operation.
I do not want to present this as a universal Codex or Sandboxie bug. Installing and activating packaged applications may involve the AppX/WinRT infrastructure and, depending on the application, COM/RPC components and services running outside the sandbox.
In my case, I have not yet identified which exact component is causing the error, so I am not claiming that COM/RPC is necessarily the root cause.
When trying to resolve this type of incompatibility in Sandboxie, it may eventually become necessary to open specific IPC endpoints, COM interfaces, services, or other host resources. The more exceptions that are required to make the application work, the harder it becomes to maintain isolation that is understandable and verifiable.
Related discussions I found
I found several discussions covering parts of this problem:-“Prevent programs to read files on host system?”
-“New privacy enhanced File/Registry access scheme” (#890)
-“How to start a sandboxed process without access to outside storage?”
-“Compartmentalization for high privacy and security”
-“Can't run programs/installers when privacy mode enabled”
-“Out-of-process COM / WinRT support” (#3850)
I also found discussions about other AI agents such as Cursor Agentic AI, OpenClaw, and Claude Code, so the broader issue of isolating this type of application already seems to be emerging.
However, I have not found a discussion focused specifically on Codex App for Windows, its read-access model, and the difficulties involved in deploying the MSIX application and then running it inside Sandboxie.
My question is:
Has a recommended configuration already been discussed for this type of AI agent using a “deny by default” model, where the processes controlled by the agent can only read the authorized workspace and the minimum system resources required to function?
I think this type of application makes it especially important for Sandboxie to control not only what a program can modify, but also what information on the system it can actually see.