Most coding agents are still optimized for one turn at a time: give it a task, wait, steer, repeat. Codex's new /goal flow is interesting because it moves the contract up a level: give Codex one durable objective, define what "done" means, and let it keep working across turns until it hits a verifiable stopping condition.

That sounds small. It is not.

What /goal actually changes

OpenAI describes /goal as an experimental Codex CLI feature for long-running work. The important parts:

• It is meant for tasks that need persistence across turns, not a single prompt. • You give Codex a clear objective and stopping condition. • You can inspect the current goal with /goal . • You can control the run with /goal pause , /goal resume , and /goal clear . • It is best for migrations, refactors, deployment retry loops, prompt/eval optimization, prototypes, and side projects where Codex can keep validating progress.

The key phrase is "verifiable stopping condition." This is the difference between "work on my app" and "migrate this route, keep the legacy path intact, run these tests after each checkpoint, and stop when the new path passes parity checks."

Why this matters for OpenClaw users

OpenClaw already gives you the surrounding operating system for agents: chat routing, cron jobs, browser automation, approvals, memory, sub-agents, and status reporting. Codex gives you a strong coding runtime. Codex OAuth is the bridge that lets OpenClaw use your ChatGPT/Codex subscription route without treating every task like a separate OpenAI API-key workflow.

The basic OpenClaw setup is:

bash openclaw onboard --auth-choice openai-codex

For headless machines or callback-hostile setups:

bash openclaw models auth login --provider openai-codex --device-code

Then you have two common routes:

openai-codex/ — Codex OAuth through OpenClaw's normal PI runner.

openai/ + agentRuntime.id: "codex" — native Codex app-server harness using Codex sign-in.

That distinction matters. /goal is a Codex CLI feature, not just a generic chat prompt. OpenClaw's role is the orchestration layer around it: schedule work, trigger checks, route updates to Telegram/Discord/etc., keep memory, and run supporting agents while Codex handles the long coding loop.

The pattern I like

Use /goal for the core coding objective:

text /goal Migrate the billing webhook handler to the new event schema. Stop when: unit tests pass, staging webhook replay succeeds, old schema remains supported behind a rollback flag, and docs are updated. Read first: docs/billing.md, worker/src/webhooks.ts, tests/webhooks.test.ts. Validate with: npm test -- webhooks && npm run typecheck. Checkpoint after each meaningful change with what passed, what failed, and what remains.

Then use OpenClaw around it:

• A cron watchdog checks whether the run is stuck. • A browser agent verifies the deployed flow. • A Telegram approval gate handles risky commands or deploys. • A memory file captures the migration decision so another agent does not relitig…

为什么值得关注

能改变理解方式，而不只是重复常识；符合当前抓取需求；它提供了新的理解或解释，而不只是表面观点

来源：reddit，领域：tech，保留分：0.70