A work browser places project, tab and file controls beside website content. Sharing a window must not mean sharing execution authority. I give web views and the app Shell different bridges and verify the request's sender again where management operations enter the main process.
Do not attach the management preload to a website view
Website create disables nodeIntegration and enables contextIsolation, sandbox and webSecurity. Its current webPreferences do not attach the Shell management preload. A page's DOM/scripts therefore do not receive the same bridge as the application's file and project controls through that configuration.
Session permission requests and device permissions are denied by default in current code too. Those settings are not certification against every effect of website content. A page still runs its document and uses networking. The implementation evidence supports separation of capabilities, not a claim of protecting the whole operating system against every threat.
The Shell does not receive unrestricted Node either
ShellView has a dedicated preload while keeping nodeIntegration off and isolation enabled. ContextBridge exposes fixed methods, rather than publishing a generic function accepting any channel and arguments for ipcRenderer.invoke.
An internal helper can bind a channel while the exposed interface remains named operations such as copying a project or choosing files. A method existing still does not mean every call is allowed. Current workspace/profile and running-state conditions are checked in the main-side contract. Bridge shape and execution eligibility therefore remain different layers.
The main process rechecks the sender and frame
Trusted verifies that event.sender is the Shell webContents, senderFrame is its main frame, and the frame URL is in the Shell scheme. A similar title or method name does not qualify as a management request. Even a read entry such as shell:getState passes that sender check.
Arguments are parsed through ShellCommands, and registration skips retired internal-CLI commands. Old types or compatibility fields do not establish an open IPC channel. The distinction between a web document and the trusted top-level management frame is therefore enforced at an actual call entrance rather than only described in a diagram.
Do not let the management surface navigate into another page
ShellView blocks will-navigate and denies new windows. A privileged surface should not navigate into another web document and continue as though its bridge had unchanged meaning. Ordinary website navigation and Shell navigation denial have different purposes even within one app window.
The source-boundary script also checks privileged renderer imports and implementation dependencies from contracts. It is a regex-based check of selected source dependencies, not proof against every runtime vulnerability or bypass. Architecture rules and sender validation complement each other while retaining their own limits.
This differs from privileges of trusted programs on the PC
This account concerns website views and the application surface. It does not claim malicious-code sandboxing for every user-authorized Python/Jupyter program or external Codex filesystem action. Trusted program execution has separate request and environment responsibilities. A small browser API should not be advertised as a restriction over the entire PC.
I read configuration, preload, main checks and the static-boundary script without launching the original browser or a new attack test. The reusable principle is to separate authority entrances rather than only visual layout, checking the current sender frame and actual arguments as well as method names. One familiar window can still retain clearly different responsibilities.