Codex becomes more useful when it can work directly with your project: edit files, run tests, generate scripts, and help verify the result. But giving an agent enough access to complete a task does not have to mean bringing your entire everyday computer into the workflow.

With Vagon Cloud Computer, you can give Codex a separate desktop containing the development tools, creative applications, and project copies it needs. You can write code, test automation, and inspect the output in the same environment while keeping unrelated personal files and browser sessions elsewhere.

That separation works best alongside Codex’s own sandbox and approval controls. A cloud computer is not an automatic security guarantee, and connected accounts or tools can extend access beyond its files.

This guide walks through setting up Codex inside Vagon, choosing appropriate permissions, adding integrations deliberately, and completing a small project without granting unnecessary access.

Source: OpenAI

Separate the Computer, Then Define the Access

There are two different decisions in this setup: which computer Codex works on, and what it can do there. Vagon addresses the first by providing a separate desktop. Codex’s security controls address the second.

For that separation to work as intended, run Codex inside the Vagon desktop. Running it on your personal computer and giving it access to a remote desktop does not relocate its local commands or file permissions.

Inside the cloud workspace, think in three layers:

These layers complement each other. A separate computer can still contain sensitive credentials. A sandbox can still permit changes to important project files. An approved connector can reach remote resources that are not stored on the computer at all.

Codex’s sandbox and approval controls also serve different purposes. A command allowed inside the sandbox may run without another prompt. A request to expand access needs separate consideration, not automatic approval because the task appears useful.

This guide uses Codex locally on a Vagon cloud computer. That is different from delegating a task to an OpenAI-managed Codex Cloud environment, which has its own configuration.

The practical goal is straightforward: give Codex a complete environment for the job, then keep its access proportional to that job. Start with selected project copies and necessary applications, and add capabilities only when the workflow requires them.

Build the Workspace Around the Applications You Need

A useful Codex workspace includes more than the agent itself. You need somewhere to inspect code, the dependencies required to run it, and any desktop applications needed to verify the result. Setting these up together lets you move from a request to a tested deliverable without repeatedly transferring unfinished work between computers.

1. Choose Performance for the Work You Will Run

Create your Vagon account and select a performance option appropriate for the project.

For ordinary code editing, lightweight scripts, or the local HTML task later in this guide, a powerful GPU is not the starting requirement. Choose hardware for the applications and processes running on the cloud computer.

Blender rendering, video processing, and local AI workloads can have substantially different requirements. You can use Vagon’s scalable performance to change compute resources while retaining your desktop, applications, and files. Save your work and stop active jobs before changing configurations.

2. Select Codex and the Supporting Applications

During Application Selection, choose ChatGPT Codex alongside the tools your task needs. For a development workflow, that might include Visual Studio Code and Python. For application automation, select the relevant creative or technical software too.

Source: OpenAI

Keep the selection focused, but complete enough to test the result. If Codex generates a Blender script, having Blender in the same environment lets you inspect the script, execute it deliberately, and check the resulting scene.

Preinstallation does not establish that every component is configured. Commercial applications may require your license, and MCP servers, plugins, or additional dependencies need separate setup.

3. Open Codex Inside the Cloud Desktop

Start the Vagon computer, open Codex there, and complete account authentication. Confirm that you are working with the cloud computer’s local environment rather than delegating to a different execution environment.

Use the desktop app as the main interface for this guide. The standalone CLI is optional; do not assume its commands are available just because the desktop application is installed.

Keep the application updated, and follow the official Windows setup guidance if installation or configuration needs attention.

4. Add a Dedicated Project Folder

Create a clearly named location, such as:

Add that folder as your project in Codex. Avoid selecting the entire user profile or a directory containing unrelated projects simply for convenience.

Before sending the first substantive task, inspect the permission selection and complete any required Windows sandbox setup. Application installation alone does not confirm that the intended sandbox is active or compatible with the environment.

Source: OpenAI

Keep the Sandbox On Before Expanding Autonomy

Before asking Codex to modify a project, check the permission selection beneath the message composer. The official Windows app guidance identifies Ask for approval as the selection used to apply sandbox protections. Avoid switching to full access simply to make setup or an unfamiliar command proceed.

The important distinction is between access already permitted by the sandbox and a request to go beyond it. Codex can perform allowed operations without prompting for every step. An approval prompt is therefore not a complete record of everything the agent does.

Start With Inspection, Then Permit Changes

For a new project, begin with a read-only inspection where available. Ask Codex to explain the relevant files and propose an approach before creating or executing anything.

Source: Microsoft

When you are ready to implement, use workspace-limited write access rather than unrestricted access. This allows useful work inside the project while retaining boundaries around other locations.

However, workspace-limited writes do not necessarily mean workspace-only reads. The files commands can read depend on the active configuration and sandbox implementation. Keep unnecessary sensitive files out of the environment instead of relying on the project selection alone.

For CLI users, /status and /debug-config can help inspect the active session and configuration. These are CLI checks, not commands you need to run in the desktop chat.

Verify Windows Sandbox Setup

Codex supports a native Windows sandbox, but the implementation available depends on the Windows version, device capabilities, and applicable policies.

Complete the supported setup flow and pay attention to errors or fallback notices. A setup step that requests administrator approval does not mean everyday sandboxed commands should run as administrator.

If setup fails, investigate the reported compatibility or policy issue. Do not treat disabling the sandbox as the standard fix. Different fallback implementations also have different protections, so “sandbox enabled” should not be read as identical enforcement on every Windows machine.

Review Requests That Expand Access

When Codex asks for additional permissions, check:

• Which path, command, or network destination needs access.

• Whether that access is necessary for the requested task.

• Whether the grant applies once or persists more broadly.

Approve the narrowest suitable request. Installing one dependency should not automatically justify unrestricted network access for unrelated commands.

Current permission profiles offer more detailed configuration, but they are beta and should not be mixed casually with older sandbox settings. Follow one configuration approach appropriate to your installed version.

Finally, fewer prompts do not inherently mean fewer restrictions. Codex can operate without approval prompts while remaining sandboxed. Full access is a separate decision that removes local sandbox boundaries. For this guide, keep those boundaries in place and review any proposed expansion deliberately.

Move Only the Files the Job Requires

Once the workspace is ready, transfer the smallest useful project set. For the handoff-page example later in this guide, that means a few non-sensitive product images, not your entire asset library or client archive.

Use Vagon Files to transfer the selected files, then place working copies in your project directory. File transfers are available even when the cloud computer is not running, so you can prepare the inputs before starting the desktop session.

A simple structure keeps the task understandable:

Keep source copies in input/, scripts and intermediate files in working/, and deliverables in output/. These names describe how the folders should be used. They do not make inputs read-only or establish an enforced security boundary.

Before transferring a repository, check for .env files, private keys, saved tokens, and configuration pointing to production services. Leave them behind unless the task genuinely requires them. If credentials are necessary, provide narrowly scoped access through the appropriate authentication mechanism rather than pasting secrets into chat.

You can record project conventions in AGENTS.md, including where outputs belong and which files should remain unchanged. Treat those as instructions for Codex, not a replacement for filesystem permissions or sandbox settings.

Preserve originals and an independent backup outside the agent’s accessible workspace. For code, a clean version-control baseline makes later changes easier to inspect. For media, retain source copies separately. Neither cloud storage nor a neatly organized folder automatically provides recovery from an unwanted edit.

Treat MCP, Skills, and Computer Use as Separate Access Paths

A project folder is only one part of Codex’s working environment. An MCP connection can reach a remote service, a skill can introduce executable scripts, and computer use can operate applications outside the project directory. Review each capability separately rather than assuming the command sandbox covers them all.

Source: OpenAI

For a first task, leave unnecessary integrations disabled. Add one when there is a clear reason, then test it with non-sensitive data before expanding the workflow.

Inspect MCP Connections and Skills Before Enabling Them

An MCP server handles requests to tools or information sources. A local server runs as a process on the cloud computer; a remote server communicates with another system. Neither should be assumed to inherit the restrictions applied to Codex’s sandboxed commands.

Before connecting a server, review its source, startup requirements, available tools, and authentication scope. A connector described as read-only still needs scrutiny: reading confidential data and transmitting it elsewhere can be consequential without changing a single file.

Skills package reusable instructions and may include scripts or supporting resources. Read those components before enabling an unfamiliar skill. Check installation steps too, since code can run before you invoke the advertised workflow.

Keep account access proportional. A connector authenticated to a test project is a different commitment from one authenticated to an organization-wide account.

Give Computer Use Its Own Permission Review

Computer Use can inspect and operate graphical applications. Its application approvals are separate from local command permissions, so grant access only to the apps needed for the task. Review persistent allowances periodically.

Source: OpenAI

On Windows, computer use operates on the active desktop and takes over foreground input. Running it inside Vagon keeps that activity on the cloud desktop rather than your everyday desktop. It does not guarantee uninterrupted operation if the Windows session becomes unavailable.

Finally, treat content returned by tools, webpages, or project files as potentially untrusted. Instructions asking Codex to expose credentials, widen permissions, or upload unrelated files deserve review, even when they appear inside an otherwise legitimate task.

Decide What Can Leave the Workspace

Keeping personal files off the cloud computer reduces unnecessary exposure, but it does not answer a separate question: where can the files you do provide go?

Consider each route independently:

Disabling network access for sandboxed commands does not make Codex an offline system. Its model and authentication connections are separate, as are hosted search and configured integrations.

For the local handoff-page task, scripts do not need internet access. Keep the output self-contained and avoid external fonts, analytics, scripts, or image-hosting services. That makes the deliverable easier to inspect and removes unnecessary destinations from the workflow.

If a later task requires downloading dependencies, review the package source and the proposed operation before granting access. Sending files to an approved destination is still a data-sharing decision. A trusted hosting service can contain repositories, accounts, or endpoints you did not intend to use.

More detailed network permissions require careful configuration. Writing a domain allowlist does not, by itself, activate enforcement: the relevant network proxy must also be active. Those rules govern applicable sandboxed command traffic, not every action available through Codex.

For confidential projects, check your organization’s requirements and the data policies applicable to your account before supplying content. Use limited credentials where a connection is necessary, and keep secrets out of prompts, generated reports, and shared logs. The goal is to approve a specific data flow, not simply to turn “internet access” on and assume everything afterward is covered.

First Task: Build a Local Project Handoff Page

A small deliverable lets you test the workflow without connecting production accounts or installing unfamiliar packages. For this example, ask Codex to build a local HTML gallery from a few product images.

The page should show image previews and filenames, with everything needed to view it contained in the output folder. You can inspect the generated files and open the result in a browser on the same Vagon desktop.

Prepare a Small Input Set

Copy a few non-sensitive PNG or JPEG images into input/. Keep the originals elsewhere, outside the workspace.

The intended result is:

The output includes copies of the images, so the gallery does not depend on access to your input directory when shared.

Ask for a Plan Before Generating Files

Start with a read-only review and use a request like this:

These instructions define the expected work. They do not replace the sandbox or establish filesystem restrictions.

Review the plan for unnecessary steps. This task does not require a web framework, package download, hosted deployment, or external image service.

Generate, Review, and Run

When satisfied with the approach, permit workspace-limited implementation. Have Codex create the script, then review it before execution.

Source: Microsoft

Check the source and destination paths, existing-file handling, and any operations that could delete or overwrite data. Filenames inserted into HTML should be escaped appropriately, and generated image links should handle spaces and special characters.

If the script requests network access or broader filesystem permissions, investigate why. Neither should be necessary for this task.

Source: OpenAI

Inspect the Deliverable Yourself

Open output/index.html manually in the cloud desktop’s browser. Confirm that every expected image appears, filenames are correct, and links resolve to the copied assets. Inspect the HTML for unexpected external references too.

Compare the input files with your preserved originals if unchanged contents matter; hashes provide a stronger check than filenames alone.

Finally, copy the complete output folder to another location and open the page again. This checks that the deliverable does not rely on its original workspace path.

A successful gallery demonstrates a useful, bounded workflow. It does not certify the environment as secure, but it gives you a concrete result to inspect before granting Codex more capabilities.

Review Changes, Remove Temporary Access, and Stop the Computer

Before closing the session, compare what Codex changed with what you requested. For the handoff-page example, that means reviewing the generated script, HTML, and copied assets. Unexpected configuration files, dependency installations, or changes outside the intended locations deserve investigation.

If the project uses Git, inspect the diff and check for untracked files. A successful test does not establish that every change belongs in the deliverable. For media projects, compare outputs with the preserved source files and check that the export contains everything the recipient needs.

Source: Microsoft

Then review any access added during the task:

• Stop temporary servers and helper processes.

• Remove permission allowances that are no longer necessary.

• Disable unused integrations and revoke disposable credentials through their issuing services.

• Review saved computer-use app approvals if you enabled them.

These are separate actions. Disabling an MCP connection does not necessarily stop an independently running server or revoke its token. Ending a Codex conversation does not automatically undo persistent changes.

Source: GitHub Docs

Preserve the Workspace Intentionally

Vagon’s persistent desktop lets you return to the same applications and project files. That convenience also means stopping the computer should not be treated as a reset that clears files, authentication, or saved permissions.

Save reviewed scripts and verified outputs, keep an independent backup where needed, and stop the computer when active work is finished.

For budgeting, distinguish Vagon compute and storage from Codex usage and commercial application licenses. Check the current Vagon pricing rather than assuming that ending an agent task ends every associated charge.

Final Thoughts

A useful Codex workspace gives the agent enough capability to complete the job without bringing your entire digital life into scope. Keep the sandbox active, transfer selected project copies, and review integrations before expanding access.

Vagon Cloud Computer brings Codex, development tools, and desktop applications into one separate working environment. You can generate, test, and inspect deliverables there while keeping unrelated personal work elsewhere.

Start with the applications your task needs and a small, non-sensitive project. Verify the output, then add capabilities deliberately as the workflow grows.

FAQs

Is Codex completely secure on a cloud computer?

No. A separate cloud computer helps keep the task away from your everyday desktop, but it does not eliminate mistakes, prompt injection, or credential exposure. Keep sandbox protections active, grant access deliberately, and verify outputs before using them.

Can Codex on Vagon access my personal computer?

Running Codex inside Vagon does not, by itself, give it access to your personal computer’s filesystem. However, transferred files, shared folders, remote connections, and connected accounts can expose additional resources. Review those access paths separately.

Does Codex support a native Windows sandbox?

Yes. Codex supports native Windows sandboxing without requiring WSL. The available implementation depends on Windows capabilities, configuration, and policies. Complete setup and check compatibility rather than assuming the intended protections are active because the application launches.

Is Codex on Vagon the same as Codex Cloud?

No. In this guide, Codex runs locally inside your Vagon cloud computer, alongside your applications and files. Codex Cloud tasks run in OpenAI-managed environments with their own configuration. Moving between them requires reviewing the relevant access and network settings.

Does disabling approval prompts disable the sandbox?

Not necessarily. Approval policy and sandbox restrictions are separate controls. Codex can operate without asking for approval while remaining inside configured boundaries. Full access is a different choice that removes local sandbox restrictions, so fewer prompts should not be confused with unrestricted access.

Do sandbox settings also restrict MCP and Computer Use?

Do not assume so. Local command sandbox settings are not a universal policy for MCP servers, connectors, browser activity, or computer use. Review each integration’s process access, account permissions, and application approvals separately.

Does Codex need a GPU?

Typical hosted-model coding tasks do not require a powerful local GPU. Choose hardware for the applications and processes Codex helps you run. Rendering, GPU-accelerated video processing, and local AI workloads may need more capable hardware than ordinary scripting or code review.

Does stopping Vagon remove saved files and credentials?

No. Stopping a persistent cloud computer is not a reset or credential-revocation procedure. Save your work, remove unnecessary access, and revoke temporary tokens through their issuing services. Keep independent backups for files you need to preserve.