Codex CLI supports both sandbox levels and approval modes. These tend to overlap; I’ve only tested approval modes. In general, the recommendation is to use auto mode if the folder you’re working in has a git repository, and to use read-only mode if it does not.
▌ Select Approval Mode
▌
▌ 1. Read Only Codex can read files and answer questions. Codex requires
▌ approval to make edits, run commands, or access network
▌ > 2. Auto (current) Codex can read files, make edits, and run commands in
▌ the workspace. Codex requires approval to work outside the
▌ workspace or access network
▌ 3. Full Access Codex can read files, make edits, and run commands with
▌ network access, without approval. Exercise caution
My first test of codex was an old standby: explaining the Cline repo.
martinheller@Mac cline % codex
╭───────────────────────────────────────────╮
│ >_ OpenAI Codex (v0.42.0) │
│ │
│ model: gpt-5-codex /model to change │
│ directory: /Volumes/Data/repos/cline │
╰───────────────────────────────────────────╯
To get started, describe a task or try one of these commands:
/init - create an AGENTS.md file with instructions for Codex
/status - show current session configuration
/approvals - choose what Codex can do without approval
/model - choose what model and reasoning effort to use
▌ explain this repository
• I'm planning to explore the repository's structure by listing top-level files
first before deciding how to approach explaining it fully. Since it's likely a
moderately complex task involving multiple components, I'll prepare to create
a plan to gather an overview and inspect key files like README and manifests.
For now, I'll use shell commands in the repo path to get a directory listing.
• Updated Plan
└ □ Inspect repository structure and key configuration files.
□ Review main source directories to understand functionality.
□ Summarize repository purpose, architecture, and key components for the
user.
• Explored
└ List ls
Read README.md, package.json
List src
Read extension.ts
List core
Read README.md
List task
Read index.ts
List webview-ui
List webview-ui
List tests
List specs
List proto
List standalone
List hosts
List vscode
List services
List api
List providers
List api
List providers
• I’m gathering key parts of the system like the extension entrypoint, front-end
webview, the controller managing tasks, the task logic, gRPC host bridging,
and services for terminal and web. I also want to highlight the Model Context
Protocol integration and look into tests, especially those using the testing-
platform and playwright. This gives a clear map of how everything fits
together and what’s covered by tests.
• Explored
└ List testing-platform
Read README.md
• Updated Plan
└ ✔ Inspect repository structure and key configuration files.
□ Review main source directories to understand functionality.
□ Summarize repository purpose, architecture, and key components for the
user.
• Explored
└ Read index.ts
List hostbridge
List packages
• Updated Plan
└ ✔ Inspect repository structure and key configuration files.
✔ Review main source directories to understand functionality.
□ Summarize repository purpose, architecture, and key components for the
user.
• I’m gathering key file references with approximate start lines to clearly
explain the repository architecture. Since exact line numbers aren’t certain,
I’ll include paths with line 1 where appropriate—like for src/extension.ts:1
and src/core/controller/index.ts:1—to lend clarity and credibility without
overcommitting to specifics. I’ll consider checking webview-ui/package.json
next to confirm React usage before citing it.
• Explored
└ Read package.json
List mcp
List browser
List integrations
List terminal
List evals
Read README.md
• I’m putting together a thorough but concise overview of the VSCode AI
assistant extension, covering its main elements like activation, core
pipeline, controllers, task engine, services, integrations, the React webview
UI, testing, evals, proto definitions, docs, and packaging. I plan to update
the progress tracking right before delivering the final message.
• Updated Plan
└ ✔ Inspect repository structure and key configuration files.
✔ Review main source directories to understand functionality.
✔ Summarize repository purpose, architecture, and key components for the
user.
• I’m organizing the final message into clear sections with bullet points like
Overview, Runtime Architecture, AI & Tooling, and next steps. I’ll include
file path references with line numbers where possible and possibly peek into
provider files to confirm accurate referencing. This way, the user gets a
structured, easy-to-follow summary of the project.
• Explored
└ Read openrouter.ts, TerminalManager.ts, McpHub.ts, App.tsx
List cline
List host
Read BrowserSession.ts, ui.proto, ChatView.tsx
Search install:all in package.json
Search "build in package.json
Read package.json
• Ran python - <<'PY'
│ import json
│ with open('package.json') as f:
│ … +4 lines
└ bash: cannot create temp file for here document: Operation not permitted
• Ran node -p "Object.entries(require('./
│ package.json').scripts).map(([k,v])=>k+': '+v).join('\n')"
└ vscode:prepublish: npm run package
compile: npm run check-types && npm run lint && node esbuild.mjs
… +7 lines
docs:rename-file: cd docs && npm run rename
report-issue: node scripts/report-issue.js
> Overview
- Cline markets itself as a human-in-the-loop agentic coding partner for
VSCode, combining editor, terminal, browser, and MCP tooling (README.md:1).
- Extension metadata, activation triggers, command registrations, and
marketplace packaging live in package.json:1, showing it targets VSCode 1.84+
and ships under Apache-2.0.
- The core architecture is documented as “extension → webview → controller →
task,” giving you the top-level mental model for how work moves through the
system (src/core/README.md:1).
Runtime Flow
- Activation bootstraps the host bridge, sidebar webview, diff providers,
and command palette entries before handing control to the controller (src/
extension.ts:1).
- The controller handles workspace discovery, auth, telemetry, MCP lifecycle,
and state sync between the extension host and webview (src/core/controller/
index.ts:1).
- Task orchestration manages API calls, context windows, tool invocations,
checkpoints, and multi-step plans while streaming partial responses back to
the UI (src/core/task/index.ts:1).
- Protobuf contracts define the bi-directional messages (asks, says, tool
calls, UI commands), letting the host, webview, and external clients talk over
gRPC (proto/cline/ui.proto:1).
AI & Tool Integrations
- A rich provider layer wraps dozens of model backends (OpenRouter, Anthropic,
Together, Bedrock, etc.) with retryable streaming support and per-model tuning
(src/core/api/providers/openrouter.ts:1 and peers).
- MCP Hub loads user-configured servers, watches configs, and proxies tool/
resource calls so Cline can extend itself with external capabilities (src/
services/mcp/McpHub.ts:1).
- TerminalManager reuses VSCode terminals, streams shell output via the new
shell-integration hooks, and captures results for the agent’s reasoning (src/
integrations/terminal/TerminalManager.ts:1).
- BrowserSession can launch or attach to Chromium and headless browsers to
automate web flows, collect screenshots, and surface console logs when tasks
require it (src/services/browser/BrowserSession.ts:1).
Frontend Webview
- The webview UI is a Vite/React app with Tailwind, Storybook, and Vitest,
bundled alongside the extension and built via dedicated scripts (webview-
ui/package.json:1).
- Providers wrap context, telemetry, and gRPC clients before rendering,
enabling server-driven state hydration and announcement handling in the
sidebar (webview-ui/src/App.tsx:1).
- ChatView composes messaging panes, token/cost analytics, quick actions, and
slash-command tooling, powered by protobuf-backed gRPC clients shared with the
host (webview-ui/src/components/chat/ChatView.tsx:1).
Testing & Ops
- A CLI-based testing platform spins up gRPC adapters and harnesses to
replay scripted conversations against the standalone server or the extension
(testing-platform/README.md:1).
- Recorded session fixtures exercise chat flows, slash
commands, and multi-root workspaces, enabling regression
checks without re-running full UI tests (tests/specs/
grpc_recorded_session_chat___can_send_messages_and_switch_between_modes.json:1
).
- The evals suite benchmarks Cline across standardized coding tasks, diff-edit
challenges, and model comparisons, with a CLI that toggles the extension into
test mode on demand (evals/README.md:1).
Next steps:
1. Install dependencies with npm run install:all (root + webview) and generate
protobuf stubs via npm run protos.
2. For local development, run npm run watch (host) in one terminal and npm run
dev:webview in another to iterate on the extension and sidebar UI together.
▌ Implement {feature}
⏎ send ⇧⏎ newline ⌃T transcript ⌃C quit 56.3K tokens used 91% context l
Token usage: total=56,294 input=48,978 (+ 918,272 cached) output=7,316 (reasoning 4,160)
To continue this session, run codex resume 01999c62-84cd-7e01-ab31-dd71d07da02b.
I’ve done this exercise with several large language models (LLMs) that have been trained on code. This is among the best summaries I’ve seen so far.
