Summary

Codex CLI already supports the experimental /goal feature for long-running tasks, but the Codex macOS app does not appear to expose, recognize, or provide feedback for it.

In the CLI, /goal can set/view/pause/resume/clear a durable objective attached to the active thread. In the macOS app, typing /goal into the composer shows No commands, and there is no visible goal state, goal status feedback, or equivalent UI affordance.

This creates a cross-surface mismatch: a long-running Codex workflow can be goal-driven in the CLI, but the same concept is invisible or unavailable in the native macOS app.

Why this matters

The official Codex docs describe /goal as a way to give Codex a durable objective for long-running work with a clear stopping condition and validation loop.

This is especially useful for:

• multi-phase implementation work
• plan execution
• long CI repair loops
• refactors/migrations
• eval or prompt optimization loops
• work that may be interrupted, compacted, or resumed later

The macOS app is exactly the kind of surface where users benefit from explicit state and feedback. Without native goal support, the app gives no indication that goals exist, whether one is active, or how to inspect/control one.

Current behavior

Codex CLI

Using Codex CLI, /goal is available and works natively.

Example CLI behavior:

› /goal

/goal  set or view the goal for a long-running task

When a goal is active, the CLI reports it in-session, for example:

Goal active Objective: $execute-plans

The CLI session can also be resumed later with the goal context still meaningful.

Codex macOS app

In the macOS app, typing /goal into the composer does not expose a slash command.

Observed behavior:

No commands

There is also no visible goal indicator in the composer, thread header, status area, command palette, or progress UI.

Expected behavior

The macOS Codex app should support /goal as a first-class feature with behavior matching the CLI as closely as possible.

At minimum:

1. Typing /goal in the macOS app should be recognized as a command, not treated as ordinary prompt text.
2. The app should support the same basic goal operations as CLI:
   • /goal <objective> to set a goal
   • /goal to view the active goal
   • /goal pause
   • /goal resume
   • /goal clear
3. If goals are behind features.goals, the app should either:
   • expose the same experimental feature toggle, or
   • clearly explain that goals must be enabled in config before use.
4. When a goal is active, the app should show visible state somewhere durable, such as:
   • thread header
   • status/sidebar area
   • compact active-goal banner
   • model/settings/status popover
5. During a goal-driven run, the app should provide feedback aligned with the CLI contract:
   • current goal objective
   • checkpoint/progress state where available
   • paused/running/complete status
   • clear blocked/error state if the goal cannot continue
6. If the macOS app cannot yet support goals, it should display an explicit unsupported-command message instead of No commands.

Suggested UX

A minimal implementation could be:

• Add /goal to the app slash-command menu.
• Add an active goal indicator near the model/status controls.
• Clicking the indicator opens a small panel:

Goal
Status: Active

Objective:
<goal text>

Actions:
Pause | Resume | Clear

A stronger implementation could also show checkpoint-style progress summaries, since the official guidance emphasizes compact progress reports for long-running goal work.

Reproduction steps

1. Enable goals for Codex CLI:

[features]
goals = true

2. Start Codex CLI.
3. Run:

/goal Complete a long-running task until final verification passes.

4. Confirm CLI accepts and reports the goal.
5. Open the Codex macOS app.
6. Type:

/goal

7. Observe that the app composer/command surface reports:

No commands

Actual result

The macOS app does not show /goal as an available command and does not provide any native goal UI or status feedback.

Expected result

The macOS app should support goal creation, inspection, pause/resume/clear controls, and visible active-goal state with parity to Codex CLI behavior.

Environment

• Codex CLI version observed: 0.130.0
• Codex CLI model/session shown: gpt-5.5 high
• Platform: macOS
• Codex surface affected: native macOS Codex app
• CLI feature: experimental /goal enabled via features.goals

References

Official docs:

• Codex CLI slash commands: /goal is documented as “Set or view an experimental goal for a long-running task” and supports set/view/pause/resume/clear.
  https://developers.openai.com/codex/cli/slash-commands#set-an-experimental-goal-with-goal

• Codex “Follow a goal” use case: goals are described as durable objectives for long-running work with a verifiable stopping condition.
  https://developers.openai.com/codex/use-cases/follow-goals

Related GitHub repo:

• https://github.com/openai/codex/issues

Impact

This is not just a missing shortcut. /goal changes the operating contract of a long-running Codex thread. If the CLI supports that contract but the macOS app does not expose it, users lose visibility and control when switching between Codex surfaces.

Native macOS app support would make goal-driven work more trustworthy, especially for long autonomous tasks where users need durable state, pause/resume controls, and clear progress feedback.