Codex Cloud/Web has compounding reliability, observability, and workflow problems that make long-running tasks difficult to trust

What issue are you seeing?

What issue are you seeing?

I have been using Codex Cloud at chatgpt.com/codex/cloud on a ChatGPT Plus account for real development work, including both smaller implementation tasks and longer unattended tasks. The main problem I have encountered is not one isolated defect, but a combination of reliability, observability, runtime, Git, context-management, and orchestration limitations that become significantly more disruptive when they occur together.

Many components of this problem already have their own reports in this repository. Existing issues cover Cloud checkouts with missing Git remotes or incorrect branches, incomplete Git publishing workflows, missing task logs, lost background processes, repeated context compaction, excessive usage during long-running commands, incomplete Cloud lifecycle controls, and late cybersecurity blocks. I am opening this combined report because these behaviors interact during real Cloud tasks, while the current interface provides relatively little information for determining what went wrong.

This report is specifically about the Codex Cloud/Web experience. It is not about ChatGPT Work or general ChatGPT Scheduled Tasks. Codex Automations in the desktop application are also a separate system. I do not currently see a native scheduling or orchestration interface in chatgpt.com/codex/cloud for periodically resuming development against a selected Cloud environment, repository, and branch.

Execution visibility is extremely limited

During a Cloud task, very little of the operational execution is visible. I am not referring to private chain-of-thought. I mean ordinary information that is useful for supervising a coding agent, including shell commands, command output, files being inspected, tests being run, tool calls, process status, errors, retries, and concise progress information.

In my current Plus Cloud UI, /plan is essentially the only useful slash command exposed in the chat interface. Once a task starts, most of the engineering process is hidden behind a minimal progress view. I cannot follow a command log closely enough to see that the agent is investigating an incorrect subsystem, repeatedly running an expensive test, retrying a failing command, or taking another inefficient path before significant time and usage have already been consumed.

This matters even when the task eventually succeeds. A successful result does not show whether the execution was direct and efficient or whether the agent spent substantial time recovering from avoidable runtime problems.

Issue #42580 demonstrates a more severe version of the same observability problem. In that report, a Cloud-triggered task could fail without exposing useful repository checkout, environment setup, command execution, or agent logs. My concern here is broader: even during a normally functioning Cloud task, the user receives very little operational information with which to supervise or diagnose the run.

There is no useful live incremental diff during execution

The final diff at the end of a task is useful, but I do not have a practical live file-by-file view while the task is still executing. I cannot follow which files are currently being created or modified, inspect changes as they accumulate, or correlate those changes with the commands and tests that produced them.

This becomes substantially more important because the command and tool execution stream is also mostly hidden. On a longer task, an incorrect implementation direction can continue for a significant amount of time before the user receives enough information to recognize it.

This does not require exposing model reasoning. Commands, test results, working-tree changes, and Git status are ordinary runtime state and can be presented independently of hidden reasoning.

Long-running and background processes are not reliable enough

I encountered a concrete failure during a long Cloud task that depended on a long-running script. The script was already partway through execution when Codex reported that it had “backgrounded” the process. After that happened, the usable process state was effectively lost. Codex could no longer continue from that execution and had to restart the script.

The Cloud interface gave me no independent way to inspect or recover that process. There was no visible process list, durable session handle, PID, current stdout/stderr, exit status, elapsed runtime, or clear indication that Codex was still monitoring it.

This makes backgrounding a required long-running command risky. If the execution is important to the task, its continued existence should not depend on the current model context retaining a transient terminal or session identifier.

Several closely related Codex reports already exist. Issue #16580 describes Codex becoming unable to access its own background process after context compaction because the required terminal/session identifier was lost. Issue #32188 requests event-driven wakeups for background exec sessions because the current model can otherwise require repeated polling. Issue #38495 documents an extreme case where a long-running exec operation degraded into repeated full-context polling and consumed 34.6 million tokens after the underlying operation had already completed.

Those issues are not all Cloud-specific, but the failure mode is especially concerning in Cloud because the user has less direct access to the runtime. There is no local terminal or process state to inspect when the agent loses track of an execution.

Runtime state is not durable enough from the user's perspective

Persistent filesystem state and persistent runtime state are different things. The Cloud environment may preserve repository files or cache parts of its environment, but I cannot rely on active process handles, terminal state, monitoring state, or awareness of previously started background jobs remaining usable across turns.

A later turn may therefore be able to see files produced by an earlier command while no longer having access to the command itself, its logs, or its process state. At that point Codex has to reconstruct what happened from the repository and conversation.

This makes Cloud feel more like repeated delegation into an environment than a persistent hosted development session.

Issue #25086 reports a related problem where Codex Cloud Web appeared to recreate or reinitialize environments more frequently than expected instead of consistently benefiting from cached environment state. Even where filesystem caching is functioning correctly, the distinction between durable filesystem state and ephemeral execution state remains important.

Git operations and repository handoff remain a major source of risk

The Git workflow in my current Cloud experience still requires significant manual involvement. I can still have a cloud agent push a resulting Cloud branch and then start another task on top of that newer branch, but this makes the Git workflow much more shaky and unreliable.

I cannot treat the Cloud agent as a normal autonomous development environment that can reliably inspect remote state, fetch the required branch, continue from the latest work, rebase or merge where appropriate, push changes, update an existing pull request, resolve an ordinary conflict, and continue working without intervention.

There are also several existing Cloud reports where the repository state itself is incorrect. Issue #40086 reports Codex Cloud receiving a detached/local checkout without the expected Git remote even though the repository and branch were selected in the UI. Issue #12498 similarly reports Cloud ending up on a local work branch with no origin remote and without the branch selected by the user. Issue #38351 reports an @codex task successfully editing, testing, and committing against an existing pull request but receiving no publishing tool to push the result back despite write access. Issue #33705 separately reports the Codex Web Create PR workflow no longer working.

These failures are disproportionately costly when they happen late. A branch or remote problem found at the start of a task is inconvenient. Discovering the same problem after a long implementation and test cycle can make the completed work difficult to publish or continue from.

The actual checkout state should also be explicit in the interface. If the repository or branch selected before submission differs from the checkout that reaches the runner, that mismatch should be visible immediately rather than being discovered later by the agent.

Context usage and compaction are effectively invisible

Another major problem is that I cannot see the context health of a Cloud task. I do not know the current context utilization, whether automatic compaction has occurred, how many compactions occurred, when the most recent one happened, or what working state was preserved afterward.

This is important for long tasks because context management can directly affect both task continuity and usage. A task may follow a clean execution path, or it may repeatedly approach the context limit, compact, reconstruct its task state, reread repository files, and repeat earlier investigation. From the Cloud interface, both may simply appear as a task that remains “working.”

The user may only see the indirect effect through a much larger reduction in available Codex usage.

There are several existing reports demonstrating why this telemetry matters. Issue #22220 specifically requests conversation-compaction telemetry and context-health information, including compaction count and the time of the latest compaction. Issue #21468 asks for compaction summaries to be visible so users can understand what state was retained. Issue #35032 reports a long-running thread that repeatedly compacted while remaining approximately 80% full afterward, causing repeated reprocessing, reduced coherence, and paid usage waste. Issue #34095 describes repeated auto-compaction degrading the current execution frontier and preventing long tasks from converging. Issue #25900 describes compaction restoring the session to the wrong semantic point, causing already completed analysis and exploration to be repeated. Issue #26783 reports repeated automatic compaction causing measurable usage drain. Issue #32888 describes a context-management failure after large tool output that can leave a long-running session unrecoverable.

Not all of these are Cloud-specific. They are relevant because a Cloud user currently has very little telemetry with which to determine whether similar behavior is occurring remotely.

Usage is visible only at a high level

Related to the context issue, Cloud does not give me enough task-level information to understand why a particular run consumed the amount of usage it did.

If a task consumes a surprisingly large share of the available allowance, I cannot determine how much resulted from ordinary reasoning, repeated repository reads, retries, context reconstruction, automatic compaction, long-running command polling, or another execution issue.

This is particularly important because Cloud removes most of the operational information that might otherwise explain the consumption. The user can see the plan-wide allowance decrease without seeing whether the individual task followed an efficient path.

Issue #38495 is an extreme example of why task-level usage attribution matters. An execution-control problem around one long-running command caused enormous additional token usage. The user should have enough visibility in Cloud to distinguish genuinely difficult work from an inefficient or malfunctioning run.

There is no model selector or reasoning-effort control in my current Cloud UI

My current Codex Cloud interface does not expose a model selector or a reasoning-effort selector. Other Codex surfaces expose reasoning as a meaningful performance and usage control, and issues such as #32724 and #34278 discuss the importance of making model/reasoning configuration visible and understandable.

If Cloud intentionally uses a managed configuration, the lack of manual selection is not necessarily itself a defect. The problem is that the current task also gives me very little visibility into what configuration actually ran and how the resulting usage should be interpreted.

The combination of fixed or hidden model configuration, no reasoning-effort control, limited context telemetry, and limited task-level usage reporting makes it difficult to understand the cost and performance behavior of a Cloud run.

Skills, plugins, MCP servers, and subagents are not exposed in my current Plus Cloud UI

In my current Plus Cloud interface, I do not see a way to attach or configure Codex Skills, plugins, MCP servers, or subagents.

The connector options currently visible to me are GitHub, GitLab (beta), Slack, and Linear. I understand that connector availability may vary by plan, workspace, account, or rollout, so I am describing the exact interface currently available to me rather than claiming the same list applies universally.

The broader issue is that the Cloud environment exposes a substantially smaller extension surface than other Codex environments. This limits tasks that depend on external development tooling or reusable capabilities.

Independent Cloud tasks and subagents also solve different problems. Launching several independent tasks can duplicate repository exploration, produce conflicting modifications, and consume usage concurrently. A subagent can instead perform a bounded investigation or review under one parent task while the primary agent retains responsibility for the overall objective. The current Cloud interface does not expose an equivalent mechanism.

Issue #30913 demonstrates that plugin/MCP profile management is already relevant to agent workflow design elsewhere in Codex, while the tracker also contains dedicated subagent and skills issue categories. The problem here is specifically their absence from the Cloud task configuration available to me.

There is no practical multi-repository or multi-branch workspace

The Cloud workflow I currently see is centered around a single selected repository and branch. I do not see a way to define one Cloud workspace containing several authorized repositories or several related worktrees or branches.

This limits tasks involving coordinated changes across an application and shared package, frontend and backend, SDK and service, or other multi-repository project structures. Running independent Cloud tasks against each repository leaves coordination and state synchronization outside the Cloud environment.

This is already a recognized limitation elsewhere in Codex. Issue #11956 requests multi-repository context for Codex App/Web, #15168 describes the need for workspace-level multi-repository support with diffs and Git state grouped per repository, and #34545 covers a related multi-repository worktree workflow.

There is no task queue or sequential dependency model in Cloud

The absence of a task queue is a larger limitation than it may initially appear. Many autonomous workflows are sequential rather than parallel. A project may have several implementation batches followed by a quality gate, with later work only making sense if the earlier gate succeeds.

Starting several independent Cloud tasks simultaneously is not equivalent. Parallel tasks can duplicate investigation, work from stale repository state, produce incompatible modifications, and consume usage concurrently.

The current Cloud interface does not expose a queue with pending, running, completed, failed, and cancelled states. I also do not see task dependencies, an explicit concurrency limit, or a way to queue future tasks while enforcing sequential execution.

Related queue behavior already exists as a concern elsewhere in Codex. Issue #28897 discusses queued tasks continuing when the five-hour rate limit is reached, and #26502 requests the ability to hold queued work for human review before later tasks continue. Those reports concern other Codex surfaces, but they demonstrate that queue state and execution order are meaningful parts of longer agent workflows.

For Cloud, the lack of any corresponding queue means the user either has to return manually between stages or start independent jobs that may overlap.

There is no native Cloud scheduling or repo-backed automation workflow

Codex Automations are available through the desktop application, but that is not the same as a native scheduling system for chatgpt.com/codex/cloud. General ChatGPT Scheduled Tasks are also a separate feature and are not repository-backed Codex Cloud jobs.

In the Cloud Web interface, I do not see a way to configure a scheduled task that explicitly targets a Cloud environment, repository, and branch and then returns to that development state at a later time.

This limitation is related to several existing reports. Issue #24777 requests a scriptable Codex Cloud environment and task-lifecycle interface, including repository-based dispatch, task status, logs, messaging, cancellation, and output retrieval. Issue #32723 describes Scheduled Tasks losing the ability to select the intended Git worktree and environment, making unattended automation workflows difficult or impossible. Issue #38576 also documents the continuing ambiguity between ChatGPT Scheduled Tasks and Codex Automations.

The current separation leaves Cloud without a clear workflow for recurring repository-backed development tasks.

Task history has limited filtering and discovery

This is less severe than the runtime and Git issues, but it becomes more noticeable as more Cloud tasks accumulate.

I would expect to be able to search or filter tasks by repository, branch, environment, status, date, or text, and to distinguish tasks that are running, failed, contain unpublished changes, or are waiting for user action.

Related discoverability problems already exist elsewhere in Codex. Issue #35686 reports a Cloud task started from the desktop app becoming impossible to rediscover from the application after navigation even though the task still existed. Issue #32182 similarly reports a recent long-running task becoming difficult or impossible to find through normal history and search.

Late cybersecurity blocking could be especially damaging for long Cloud runs

I have not personally reproduced this specific failure inside a long Codex Cloud task, so I want to distinguish it from the issues above that I directly observed.

I have encountered whole-message cybersecurity blocking in regular ChatGPT and once while using the Codex CLI. There are also current Codex reports where benign engineering work was allowed to execute for a significant amount of time before a cybersecurity safeguard terminated the run.

Issue #40970 documents a competitive-programming optimization task that ran for approximately 21 minutes, performed substantial work, used subagents, produced benchmark output, and edited files before being terminated by a cybersecurity block. Issue #42681 describes repeated cybersecurity detection while working on an ordinary WebAssembly compiler. Issue #43453 describes opaque security blocks repeatedly interrupting long-running unattended engineering work without making it clear what action caused the block or whether the task could safely continue.

The concern is how a late safety decision would interact with a long unattended Cloud task. If policy requires the resulting output to be withheld after the block, preserving the blocked output may not be possible or appropriate, which makes earlier detection especially important.

Where policy permits, another possible mitigation could be to continue the remaining work using a model or configuration appropriate for the detected capability level instead of invalidating an otherwise long-running task. I mention that only as one possible approach. The underlying issue is the potential for a restriction discovered very late to make hours of otherwise legitimate execution and usage unusable.

Combined impact

Each of these limitations can be described independently, but their interaction is the main problem.

A long Cloud task can begin with very little execution visibility, start a required long-running process, lose access to that process after it is backgrounded, reconstruct part of its state from the repository, grow its context without exposing context utilization, compact one or more times without exposing that history, consume substantial usage without task-level attribution, complete the implementation, and then encounter a branch, remote, or publishing problem.

From the user's perspective, this is not experienced as a collection of unrelated issues. It means that long Cloud work has several important failure points while exposing relatively little information for detecting or diagnosing them.

This also creates an awkward workload boundary. Smaller tasks benefit from command visibility, live changes, and fast intervention. Longer tasks depend increasingly on durable process management, context health, Git reliability, task-level usage information, and failure recovery. These are currently some of the least visible or controllable parts of the Cloud environment.

The result is that the workflow I can currently trust most is a relatively bounded asynchronous task in one repository and branch, using ordinary short-lived commands, limited external tooling, and little need for intervention while it runs.

What steps can reproduce the bug?

What steps can reproduce the bug?

Because this report concerns several compounding Cloud behaviors rather than one isolated defect, there are several reproducible cases.

A. Long-running process state
Open Codex Cloud/Web and start a task in a connected repository.
Give the task work that requires a script or command that runs for a significant amount of time.
Allow Codex to start that command and continue working.
If Codex backgrounds the command, attempt to locate a persistent process/job object, live output, exit status, or durable process handle in the Cloud UI.
Continue the task or send a later turn.
In my reproduction, Codex eventually could not continue using the original execution and had to restart the script because the useful process state was lost.
B. Execution and live-change observability
Start a non-trivial Cloud coding task that requires repository inspection, edits, tests, and shell commands.
Observe the task while it is running.
Attempt to determine the exact command currently executing, its output, what files are being inspected, which tests have completed, what files have changed so far, and the current Git status.
In my current Plus Cloud UI, most of this information is not available while the task executes.
C. Context and usage visibility
Start a long Cloud task that performs many repository reads, commands, edits, and tests.
Allow the task to run long enough that context compaction may reasonably occur.
Attempt to inspect current context utilization, compaction count, latest compaction time, the retained task-state summary, and usage attributable to that task.
In my current Cloud UI, I cannot see this information.
The most visible usage signal is the reduction of the broader Codex allowance.
D. Sequential Cloud workflow
Prepare several dependent implementation batches with a validation or quality gate between them.
Attempt to queue the tasks in Cloud while limiting execution to one active task.
Attempt to make a later task conditional on the earlier task or validation stage succeeding.
Attempt to schedule the sequence against a specific Cloud repository, branch, and environment.
In my current Cloud UI, I do not see queue or dependency controls, configurable concurrency, or native repo-backed Cloud scheduling for this workflow.
E. Cloud task controls and extension surface
Open a new Codex Cloud task on Plus.
Inspect the available task and chat controls.
Attempt to select a model or reasoning-effort level.
Attempt to attach a Skill, plugin, MCP server, or subagent.
Attempt to create a workspace spanning multiple repositories or related branches.
In my current interface, those controls are not exposed. The connector choices visible to me are GitHub, GitLab (beta), Slack, and Linear.

What is the expected behavior?

What is the expected behavior?

Long-running Cloud tasks should expose enough runtime information for users to understand and supervise their execution. Commands, useful command output, test state, file changes, and Git state should be inspectable without requiring access to private model reasoning.

A required long-running or background process should remain identifiable and inspectable after it is started. The user and agent should not lose access to a required process because a turn ended or context was compacted. If some categories of process state are intentionally ephemeral, that limitation should be clear before a required command is moved into the background.

The repository checkout should consistently match the repository and branch selected by the user. Completed work should have a reliable handoff through Git or a deterministic fallback if publication fails, particularly after a long task has already consumed substantial time and usage.

Long-running Cloud threads should expose enough context and usage telemetry to determine whether the task has compacted repeatedly, reconstructed state, or entered another inefficient execution pattern. It should also be possible to understand the usage attributable to an individual Cloud task rather than only seeing the plan-wide allowance decrease.

The Cloud task should clearly identify its model and reasoning configuration if those settings are managed by the service. If user-selectable controls are supported, they should be exposed consistently.

For longer multi-stage work, the Cloud environment should have a reliable way to represent queued or dependent work instead of requiring either manual relaunch between every stage or overlapping independent tasks. Similarly, if recurring Cloud development is supported, the execution target should clearly identify the relevant repository, branch, and environment.

Additional information

Additional information

I searched the existing tracker before filing this report. The following issues appear directly or closely related.

Codex Cloud / Web, Git, lifecycle, and handoff
#40086 — Codex Cloud creates detached work checkout with no Git remote
#12498 — Codex Cloud stops recognizing Git remote and only references work workspace
#38351 — GitHub @codex work task gets no tool to push back to existing PR despite write access
#33705 — Bug in codex web create PR for GitHub
#42580 — Slack @Codex tasks fail silently before cloud runner starts (no logs), while identical manual Cloud tasks work
#25086 — Codex Cloud Web does not reuse cached environment and runs full setup on every new message/session
#24777 — Add scriptable Codex Cloud environment and task lifecycle management
Long-running/background execution
#16580 — Codex is not able to access its own background processes after compactation
#32188 — Event-driven wakeup when background exec sessions complete
#38495 — Code-mode exec silently degrades a long-running command into a full-context model polling loop (34.6M tokens burned after the task already completed)
Context, compaction, and usage
#22220 — Conversation Compaction Telemetry / Context Health
#21468 — Make /compact summaries visible and support prompt-guided compaction in Codex CLI
#35032 — Codex Desktop auto-compaction completes but leaves long-running thread ~80% full, causing repeat compaction and usage waste
#34095 — Repeated auto-compaction degrades execution frontier and prevents convergence in long tasks
#25900 — Compaction should preserve the current task checkpoint to avoid restart loops in long-running sessions
#26783 — gpt-5.5 reports 2432-token context window in 0.137.0, causing repeated auto-compaction and usage drain
#32888 — Auto-compaction uses stale token usage after tool output, causing unrecoverable context overflow
Multi-repository/workspace behavior
#11956 — Multi-repo support
#15168 — Workspace-level multi-repo support in Codex app
#34545 — Can worktree creation be supported for projects with multiple Git repositories?
Queueing and automation
#28897 — Pause queue execution when 5-hour rate limit is reached
#26502 — Add a “hold queued tasks” control for human-in-the-loop review
#32723 — Restore worktree & environment selection for Scheduled Tasks
#38576 — Clarify scheduling limits for ChatGPT Scheduled Tasks vs Codex automations
Task/history discoverability
#35686 — Cloud task started in Codex Desktop disappears after navigating to another thread
#32182 — Recent Codex task missing from history after new ChatGPT desktop update
Safety during long-running work
#40970 — Safety false positive: Codeforces optimization run blocked as cybersecurity after substantial execution
#42681 — Working on a WebAssembly compiler repeatedly blocked by cybersecurity detection
#43453 — Repeated Opaque Security Blocks Make Codex Unreliable for Unattended Engineering Work

Some of these reports concern the desktop app or CLI rather than Codex Cloud directly. I have included them where they document runtime, context, queueing, or safety failure modes that become particularly difficult to diagnose when the corresponding Cloud execution exposes much less operational state.

The purpose of this report is not to duplicate each linked issue. It is to document the combined effect these reliability and observability limitations have when Codex Cloud is used for longer autonomous development work.

Start with the Codex Cloud/Web surface at chatgpt.com/codex/cloud and compare the reported behaviors with issues #42580, #40086, #22220, and #38495. Because this report combines observability, process, Git, context, usage, and orchestration concerns, split it into narrowly scoped changes with explicit acceptance criteria; no single file, test, or completion condition is named here.