The Codex CLI vs Codex web decision is not just a UI preference. It is a source-of-truth decision.
Do you want the agent working in the local checkout that already has your dependencies, branches, secrets, fixtures, and tools? Or do you want to delegate a task to a separate cloud environment and review the result afterward?
Both workflows can be useful. The wrong choice creates friction. If the task depends on your local environment, local execution matters. If the task is detached and well-scoped, a cloud workspace may be enough.
Junction fits the local-first side of that decision. It lets you keep Codex running on your machine through the CLI while using a browser or phone-friendly control surface for monitoring, approvals, diffs, and Git state.
The basic difference
OpenAI describes Codex CLI as a local terminal agent. It can read, change, and run code on your machine in the selected directory.
OpenAI describes Codex web as a way to delegate work to Codex in the cloud. Codex cloud can work in the background, including in parallel, using its own cloud environment. It can connect to GitHub repositories and create pull requests from its work.
That gives you two different execution models:
| Workflow | Where the work happens | Best fit |
|---|---|---|
| Codex CLI | Your local machine and selected directory | Tasks that depend on local tools, local state, or tight supervision |
| Codex web | Codex cloud environment | Detached tasks that can run against a configured cloud workspace |
| Codex CLI with Junction | Your local machine, supervised from a browser | Local execution with remote visibility and control |
The choice is not about which product is universally better. It is about where the agent should execute for this task.
When local execution matters
Use a local Codex workflow when the task depends on the environment you already maintain.
That includes:
- local databases,
- private test fixtures,
- uncommitted files,
- local package caches,
- internal services,
- authenticated CLIs,
- project-specific scripts,
- environment variables,
- worktree or branch state,
- and tools that are not easy to recreate elsewhere.
These are not rare edge cases. They are normal parts of real software projects.
If the task is "fix the failing test in my current branch," the current branch matters. If the task is "update a migration and run the local integration suite," the local database and test setup matter. If the task is "review this uncommitted diff before I push," a cloud workspace may not even have the state you need reviewed.
When Codex web can fit
Codex web is useful when the task can be delegated cleanly to a configured cloud environment.
Good candidates include:
- well-scoped repository tasks,
- background work that does not need your current local checkout,
- pull request creation from a clean branch,
- exploration where the cloud environment has enough dependencies,
- and parallel tasks where a hosted workspace is acceptable.
This is not a weaker workflow. It is a different workflow. If the task does not depend on local state and you want asynchronous background execution, cloud delegation can be convenient.
The problem comes when a task looks detached but actually depends on your machine. In that case, you may spend more time reconciling environment differences than the agent saved.
Where Junction fits
Junction is for the local-first path.
The daemon runs on the machine that owns the code. Codex runs there too. The Junction app gives you the control surface from a browser or phone:
- live output,
- session state,
- approval prompts,
- changed files,
- diff review,
- Git and pull request context,
- stop and follow-up controls,
- push notifications when work needs attention.
The important part is that the browser does not become the runtime. Your local machine remains the runtime. Junction gives you remote supervision without asking you to move the repository into another workspace.
If you want the phone-specific version of this pattern, read How to Monitor Codex from Your Phone Without a Cloud Sandbox. This article is narrower: choose the right execution location first.
A practical decision matrix
Use this rule:
| Situation | Better default |
|---|---|
| The task depends on uncommitted local changes | Codex CLI |
| The task needs local databases or services | Codex CLI |
| You need to approve commands as they happen | Codex CLI with Junction |
| You want to monitor from a phone while execution stays local | Codex CLI with Junction |
| The task can run from a clean repository snapshot | Codex web may fit |
| You want multiple detached background tasks | Codex web may fit |
| You need a browser control surface for local execution | Junction with Codex CLI |
The matrix is intentionally conservative. If you are unsure whether local state matters, assume it does until proven otherwise.
Example: local-first is the right call
You are halfway through a branch that changes billing plan copy. A test is failing locally because the component and test fixture disagree on the plan label.
This is a local-first task. The agent needs your current branch, not just the default repository state. It may need uncommitted changes. You probably want to see the exact files it touches and approve the final test command.
Run Codex locally. Use Junction if you want to supervise the run from another browser or phone. Review the changed files before turning the branch into a pull request.
Example: cloud delegation may fit
You want a small documentation update on a repository with straightforward setup. The issue is clear, the change does not depend on your local checkout, and the expected output is a pull request.
That may fit Codex web. The cloud environment can handle the detached task, and you can review the resulting PR when it is ready.
The key is not the file type. It is whether the task needs the state on your machine.
Do not confuse remote control with remote execution
Remote control means you can steer a local process from another surface. Remote execution means the process runs somewhere else.
Junction is a remote control surface for local execution. Codex web is a cloud execution surface. Codex CLI is local execution through the terminal. Codex CLI with Junction is local execution with a browser control plane.
Keeping those concepts separate prevents bad assumptions. If you want your code, tools, and credentials to stay on your own machine, choose the local path. If you are comfortable delegating the task to a cloud environment, choose the cloud path.
Tradeoffs worth acknowledging
Local execution means you are responsible for the machine. If it sleeps, loses network access, or lacks dependencies, the workflow is affected. You also need to manage your local agent CLI setup.
Cloud execution means you need to configure the cloud environment and accept that it may not match your local machine exactly. It can be convenient, but it is not the same source of truth as the checkout you are actively using.
Junction does not remove those tradeoffs. It gives the local path a better control surface.
Start with the local path when the repo matters
If the repository state on your machine matters, start with Codex CLI and Junction. Install the daemon, pair the app, confirm Codex works locally, and run one bounded task.
Use the Junction setup guide to connect the first daemon. If you need more daemon connections or open chats after the workflow proves useful, compare pricing.