Orply.

Codex Cloud Lets Developers Delegate Larger Tasks Without Managing More Machines

Dominik KundelOpenAIWednesday, October 7, 20267 min read

At DevDay 2026, Dominik Kundel argued that as developers delegate longer-running, more complex work to Codex, they should not have to keep a laptop open or provision additional machines to run it. He presented Codex Cloud, alongside the CLI, app and web interfaces, as a way to move tasks between environments while keeping their context and access to tools. The demonstrations also showed practical limits: cloud machines still constrain what can be built, and private services require explicit network configuration.

Bigger agent tasks have made the laptop part of the infrastructure

Dominik Kundel described a shift from running one or two tasks to handing agents larger problems that can run for hours or days. That work creates a practical burden: keeping a laptop open between meetings, buying a Mac mini or Raspberry Pi, or renting a virtual server. More machines mean more upkeep, disk space, updates, and capacity to manage. Kundel’s central claim is that delegating work should not require procuring more computers.

Delegating work should be as easy as just telling Codex to do something, and it picks up the work regardless of whether you have to go and procure more computers.

Dominik Kundel
300+
Codex features launched over the past year, according to Kundel

Kundel said the Codex app made switching between tasks and delegating work easier, and that running multiple agents had since become almost the norm for him. He recalled that seeing someone operate around 40 Codex instances at once had initially felt overwhelming. As models became more capable, particularly at computer use and long-running work, developers began handing them bigger problems.

Codex Cloud is presented as a way to move that work off a developer’s own machine. It joins the app, web, and CLI, with integrations for ChatGPT in Slack and Teams. Kundel said these interfaces use the same Codex agent and can access the tools and information available through plugins installed in a user’s account. His stated aim is for people to choose the interface and where work runs, without starting over when they change how they access Codex.

Cloud environments prepare projects, but the machine still sets limits

A cloud task needs a usable project environment. In the demo, Kundel selects two repositories for a Blossom Music project and asks Codex to prepare them. The agent inspects the repositories and dependencies, installs prerequisites, and checks the development workflow. It also proposes an install script and a startup skill: instructions for the agent on how to use the environment.

The preparation is meant to reduce the manual configuration Kundel said had made cloud environments cumbersome. It can also identify what the machine cannot do. In this case, the environment is Linux. Codex identifies that the web app can be built and tested there, but the iOS app requires macOS, Xcode, and an iOS simulator. The Linux environment can support editing the mobile source, not building or running the app.

Setup resultWhat Codex reported
Web appDependencies installed; all 3 tests passed; production build passed; app and audio servers served successfully
Browser playbackNot tested
iOS app on LinuxSource editing available; building and running require macOS, Xcode, and an iOS simulator
Environment configurationSaved but not published; repository files unchanged
Codex’s reported results and limits for the Blossom Music environment setup

The setup log also exposes a dependency issue: the repository’s lockfile pointed to an internal package registry that returned access errors. Codex proposed fetching the same locked packages from npm’s public registry while preserving the lockfile’s integrity checks and leaving repository tracking configuration unchanged. The completed setup reported the results summarized above. Kundel could review the proposed scripts before accepting them, and could return later to revise the environment, its network access, secrets, or environment variables. He could also choose whether to share it with his team.

Kundel described filesystem snapshots intended to make subsequent tasks start faster, along with background updates to incorporate repository changes and other necessary scripts. Bringing a user’s own cloud environments was described as a future capability, not one demonstrated as available.

A cloud task can connect design work to code and private services

Kundel’s shader example begins with a music-player design in Figma. He sends an app screenshot to a cloud environment and asks Codex to implement the design in the playing screen. Codex pulls details from Figma using a plugin installed in his account, works on the implementation, tests it, and creates a video of the result. When the video does not load in the desktop app, Kundel asks Codex to turn the shader into a small playground.

The resulting site offers controls for adjusting the shader, along with presets and a reset option. Kundel can try settings before sending further changes back to the app. He can also inspect the files Codex changed, leave comments on the code, or open a side chat to ask questions about the task. In a later browser demonstration, the task conversation, video, and deployed playground appear together.

The environment can also reach resources that are not open to the public internet. Kundel demonstrates an API running on a Raspberry Pi on his Tailscale network. He says he configured the environment with a Tailscale authentication key; he also noted that OpenID Connect support is available for accessing cloud resources. In the live check, a request to the API does not respond until his laptop connects to the same Tailscale network. A separate Codex task then checks the API and visualizes its results. Because service outages interfered with the demonstration, Kundel switched to a backup recording for that task.

These examples depend on configuration: the shader task used a Figma plugin, and access to the private API required network setup. The Linux environment’s inability to run the iOS app remained a separate constraint.

Slack separates personal delegation from shared collaboration

Slack brings Codex into team work already happening in channels and threads. In one example, a colleague reports that a web music player appears to have outdated visuals. Kundel asks ChatGPT in the Slack thread to investigate. The agent finds the relevant pull request, consults the Figma files, and identifies an open, unmerged PR that already addresses the redesign. After Kundel asks it to investigate further and test the changes, it uses a cloud environment shared with his organization. The work brings the PR to a point where it is ready for review.

A second example uses a personal agent Kundel calls his “dot.” A colleague had tagged him in a pull request that he missed. His dot sent a reminder, and Kundel asked what the PR concerned before requesting a more thorough review. The dot started a cloud task from Slack and reported back. Kundel could later ask follow-up questions or continue using the task to help finish the PR. In the displayed result, the agent reports no actionable bugs or regressions and says all 92 tests and the build passed.

The distinction between the two agents is about whose work they support and what they can access. A dot is an extension of its user, named to make that connection legible to colleagues. It can carry context about the user’s work, monitor channels the user cares about, contribute when permitted, and take on tasks forwarded to it. Kundel describes it as suited to ongoing responsibilities and personal delegation. ChatGPT, by contrast, is intended for collaboration with colleagues in a shared thread. A dot can access the user’s cloud environments and local Codex instances; ChatGPT can access only shared cloud environments.

Review and planning become part of delegated work

As agents write more code, reviewing it takes on greater importance. Codex’s revised desktop code-review tab brings pull requests assigned to the user, or created by them, into the app. Reviewers can inspect code and other people’s comments, leave comments, submit review feedback, or ask Codex to review. The side chat lets a reviewer ask questions while looking at the PR—for example, about its potential impacts—then submit feedback when ready.

Planning gets a shared workspace in Space, where a team can work with an agent without moving information back and forth between a planning document and Codex. In the example, Codex drafts a plan for redesigning an API reference and its deployment. Kundel puts the plan in Space, shares it with teammates, asks Codex to add a system diagram, and includes a task tracker. Codex can update that tracker as work proceeds, and other agents on the team can contribute to the same document. Once the plan is ready, the team can ask Codex to implement it and have progress information continue to flow back into the document.

The interface can change without moving the work

Kundel’s CLI and browser demonstrations extend the same shift: the work can continue in Codex Cloud while the developer changes how they access it. The CLI’s agent view lists running tasks, indicates which need attention, and supports starting more tasks in parallel. Kundel also described mentioning plugins, faster text selection, rendering diagrams and LaTeX in the terminal, and voice mode. The microphone was not enabled during his demonstration.

In the browser, he showed the shader task, its video, and the deployed playground, along with access to a user’s dot. Code review in the web app, however, was presented as forthcoming in the coming days, not as a feature already demonstrated. The point of these interfaces is not that every developer needs to use all of them; it is that work and its context can remain available across them.

Kundel recommended three starting points based on the work people already do: Codex Cloud for tasks that would otherwise keep a laptop open or require maintained dev boxes; Space for keeping plans and progress together for agents and teams; and a dot for ongoing responsibilities that would otherwise require repeated manual prompts. The larger change he described is from delegating individual tasks toward giving agents bigger problems and goals—without making developers procure and manage a separate machine for every expansion in workload.

The frontier, in your inbox tomorrow at 08:00.

Sign up free. Pick the industry Briefs you want. Tomorrow morning, they land. No credit card.

Sign up free