Aware of #22049/#21125: /goal disappeared in Mac app despite native Goal evidence, features.goals=true, and GoalBuddy confusion

Summary

Aware of related issues #22049 and #21125, but this report adds the missing regression evidence.

In #22049, OpenAI replied that native /goal is "coming to the app soon," and a later commenter said it can be enabled in the app by enabling the feature flag. In #21125, the earlier closure said /goal had not yet been integrated into the app.

That does not match the current evidence from Codex Mac App 26.506.31421: the desktop app did accept a /goal ... message less than two days ago, created a native thread goal through the built-in create_goal tool, displayed the native "Goal complete" card, and then stopped exposing /goal in the slash-command UI even though features.goals = true.

This looks like a Codex Mac app feature-gate / slash-command surfacing regression, not a simple unsupported-feature case.

Environment

• Codex Mac App: 26.506.31421
• App bundle version: 2620
• App bundle identifier: com.openai.codex
• Codex CLI: 0.130.0-alpha.5
• Platform: macOS 26.5, build 25F71
• Architecture: arm64
• Model/reasoning shown in current app session: GPT-5.5 High
• Mode when reproduced: local / "work locally", not cloud
• Config: [features] goals = true
• codex features list: goals experimental true

What happened

1. /goal used to work in the Codex Mac app on this machine.
2. A thread started with a literal /goal Follow <redacted local goal board path>.
3. The assistant then called native Codex create_goal.
4. The same thread later called native Codex update_goal with status: complete.
5. The Codex UI displayed the native "Goal complete" card.
6. After restart, /goal no longer appears in the app slash menu. Typing / shows commands like Chat, Code review, Fast, Feedback, MCP, Memories, Model, Personality, Pet, Plan mode, Project, but no Goal.

Decisive evidence

1. The archived app session contains the literal user message:

``text
/goal Follow <redacted local goal board path>.
``

1. The same archived session immediately shows native Codex goal creation:

``json
{
"type": "function_call",
"name": "create_goal",
"arguments": {
"objective": "Execute the <redacted> GoalBuddy board at <redacted local path> through verified completion."
}
}
``

1. The create_goal output returned a real native goal object:

``json
{
"threadId": "019e18f3-...-8db2dc866592",
"status": "active",
"tokensUsed": 0,
"timeUsedSeconds": 0
}
``

1. The same archived session later called native Codex update_goal:

``json
{
"type": "function_call",
"name": "update_goal",
"arguments": {
"status": "complete"
}
}
``

1. The update_goal output returned:

``json
{
"status": "complete",
"tokensUsed": 443933,
"timeUsedSeconds": 1118
}
``

1. The visible desktop UI displayed the native Goal card with:

``text
Goal complete
Complete · 18m 38s
Session: 019e18f3-...-8db2dc866592
``

1. Local config is not the problem:

``toml
[features]
goals = true
``

1. CLI feature resolution is not the problem:

``text
goals experimental true
``

1. The Codex Mac app bundle still contains native goal UI strings and app-server/client goal plumbing, including:

``text
Goal complete
thread/goal/updated
thread/goal/cleared
ThreadGoalGet
ThreadGoalSet
ThreadGoalClear
``

1. The compiled composer code appears to gate the visible goal action on an additional app-side rollout gate:

``js
Qi("3074100722") && config.goals === true && composerMode !== "cloud"
``

That means documented features.goals = true is not sufficient for the app UI if this hidden gate is false or missing.

1. Official docs currently say /goal is available when features.goals is enabled:

``text
/goal is experimental and only available when features.goals is enabled.
``

They do not mention the additional app-side gate.

1. The local thread_goals SQLite table is now empty even though the archived rollout contains the native create/update events. That suggests thread_goals is not a durable completion ledger and should not be used as proof that native goals were never active.

1. GoalBuddy makes this more confusing, but it is not the root cause. GoalBuddy currently contributes a plugin/skill surface such as $goal-prep, "Goal Prep", and Scout/Worker/Judge helpers. When native /goal disappears, the user can still see GoalBuddy/Goal Prep surfaces, creating the false impression that GoalBuddy replaced or swallowed native Codex Goals.

1. GoalBuddy also has its own Codex-native plugin install model, marketplace checkout, plugin cache, bundled skill, compatibility skill history, and separate Scout/Worker/Judge agents. In practice, that means a user troubleshooting missing native /goal can see multiple adjacent GoalBuddy surfaces while the actual native Codex /goal action is hidden by an app-side gate.

1. This exact combination creates a bad diagnostic trap:

• native goal runtime exists;
• native goal card exists;
• /goal worked recently in the desktop app;
• features.goals is enabled;
• docs say that should be enough;
• app slash UI still hides Goal;
• GoalBuddy remains visible as an adjacent plugin/skill layer.

1. The trap is worse because GoalBuddy's own doctor currently reports Codex goal runtime as ready while also returning exit code 1 when standalone skill paths are intentionally absent in a plugin-only installation:

``json
{
"skill_installed": false,
"compatibility_skill_installed": false,
"installed_agents": [
"goal_judge.toml",
"goal_scout.toml",
"goal_worker.toml"
],
"goal_runtime": {
"codex_cli_available": true,
"codex_version": "codex-cli 0.130.0-alpha.5",
"logged_in": true,
"goals_feature_enabled": true,
"goals_feature_stage": "experimental",
"ready": true
},
"warnings": []
}
``

This creates another false signal: runtime ready, no warnings, but nonzero exit because the plugin-only model does not have the old standalone skill paths.

Expected behavior

If features.goals = true and the thread is local, Codex Mac app should expose /goal in the slash-command UI, or the app/docs should explicitly say why it is unavailable.

At minimum, the UI should distinguish:

• native Codex Goal mode / /goal;
• GoalBuddy plugin / $goal-prep;
• any hidden rollout gate that can override features.goals.

Actual behavior

The app hides /goal from the slash-command UI despite:

• local mode;
• features.goals = true;
• CLI feature resolution showing goals experimental true;
• native goal runtime and goal-card evidence from a recent desktop session.

Why #21125 does not fully cover this

#21125 was closed with "not yet integrated into the app." This report shows the app did use native /goal, native create_goal, native update_goal, and native "Goal complete" UI in a real desktop session after that discussion.

So either:

1. /goal became partially integrated and is now hidden/regressed by app-side gating; or
2. there is an undocumented rollout path where some users can create native goals in the app but later lose the command despite features.goals = true.

Either way, the current behavior and documentation conflict.

Relationship to #22049

#22049 is closer to this bug than #21125 because it tracks native macOS app /goal support and remains open. This report adds the regression details that #22049 did not have:

• a real desktop app /goal invocation;
• native create_goal and update_goal evidence;
• native "Goal complete" UI evidence;
• current Codex Mac App 26.506.31421 evidence;
• the hidden app-side gate condition;
• the GoalBuddy confusion layer;
• the mismatch between features.goals = true and app UI availability.

Other similar issue checked

• #21786 mentions /goal in a different context: assistant self-looping with a superpowers brainstorming command. That appears separate from this app slash-command availability regression.

Privacy note

Local filesystem paths, user names, and private project names have been redacted. The issue is reproducible from the public behavior and the non-private implementation evidence above.