[FEATURE]: Add native session goals with /goal

Feature hasn't been suggested before.

I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

OpenCode has custom slash commands, but there is no native persistent session goal/lifecycle feature.

Proposal: add one persisted goal per session, exposed through shared server APIs so TUI and desktop app clients can view, set, edit, pause, resume, clear, and observe it. Active goals can continue when idle, track token/time usage, support optional token budgets, and let the model mark a goal complete only after verification.

This is not implementable as a command template because it needs persistence, runtime continuation, usage accounting, and client sync/status surfaces.

Related but broader than #23578 and #18636: this request covers a first-class per-session goal domain, shared API/SDK surface, TUI and macOS app support, runtime continuation, and model-visible goal tools with restricted mutation semantics.

+1

I’ve been switching from OpenCode to Codex for two weeks now. Its goal feature is incredibly useful and has greatly automated my workflow

Rewritten as a plugin per maintainer feedback — zero core code changes.

The implementation is in PR #28610. How it works:

A built-in plugin registers create_goal / update_goal / get_goal tools and the /goal command
State is stored in .opencode/goals.json (no SQLite migration needed)
Continuation loop uses the session.status idle event + client.promptAsync() to inject a <system-reminder> prompt for the next LLM turn
/goal pause|resume|clear subcommands handled inline, no LLM call
34 tests covering the full plugin lifecycle (18 unit + 16 integration)

The PR is ready for review.

+1

wtf, don't force me to re-install codex

+1

@nexxeln

this is not planned as of yet but keeping this open to see if there's more interest

@nexxeln still not planned? how much more interest is needed?

+1

+100

+1

need this

+1

+1

+1 this is an incredible feature in Codex/Claude when used correctly

feat(session): native per-session goals with autonomous pursuit

Once you get the buggy opencode-goal-plugin, it's very hard to go back, this is necessary!

+1

https://github.com/devinoldenburg/opencode-goal-mode

+1

@nexxeln

@nexxeln I think there's enough interest in this?

Any updates?

I recently switched from Claude Code to OpenCode, but I find it hard to believe that OpenCode doesn't support the /goal command—a feature I considered fundamental—and apparently has no plans to support it for the time being...?🫪

any experience which goal plugin is better?

https://github.com/devinoldenburg/opencode-goal-mode

https://github.com/prevalentWare/opencode-goal-plugin

any experience which goal plugin is better?

Choose whichever fits your workflow better.

The main difference is that my plugin follows the principles of Claude Code Goal Mode, while his follows the principles of Codex Goal Mode.

Mine used to be pretty bloated and somewhat over-engineered, which is why I refactored it a while ago. I haven’t had any issues with it since, but if anything comes up, just open an issue and I’ll take a look.

Once I make it fully stable and production-ready, I’ll try to turn it into a proper PR instead of keeping it as a standalone plugin, since most current implementations seem to follow Codex-style principles.

+1

Some people point out that OpenCode is merely an open-source project, not a community-driven one. It has its own management team and roadmap.

Instead of complaining, why not just switch to Codex? I already use Codex heavily, including with custom providers.

Some people point out that OpenCode is merely an open-source project, not a community-driven one. It has its own management team and roadmap.

Instead of complaining, why not just switch to Codex? I already use Codex heavily, including with custom providers.

Perhaps not a bad idea, comparing those two, it seems codex has much smaller idle RAM footprint. My idle opencode session is taking now over 966 MB RAM. So not only we can free up RAM, but have native goal.

It has its own management team and roadmap.

Where is the roadmap?

Instead of complaining, why not just switch to Codex?

Plenty of people aren't complaining and are here exactly because they'd prefer to use opencode over codex or other options.

On a related note grok-build's source has been recently uploaded as apache-2.0.
This is relevant for 2 reasons:

it's another option for anyone who wishes to use a different tool for the time being which has /goal.
since they've ported some of the opencode tooling/concepts/code/prompts I don't see any reason why the same couldn't be done in reverse to adopt /goal

Either way I'd guess it'll at earliest come after opencode 2 lands:

Are there any functional differences?

not a crazy amount of user facing things
...
- background agents
...

https://x.com/thdxr/status/2075668285199151312?s=20

I've been using this goal plugin in the meantime, semi-successfully, but better than no goal feature
https://github.com/prevalentWare/opencode-goal-plugin

Bumping this, xAI open-sourced Grok Build (xai-org/grok-build) and it has a working /goal implementation. Worth checking out as a reference. It does plan → execute → verify loops with separate subagents for planning, verification, and a "strategist" that kicks in when the agent keeps failing verification without converging. Apache 2.0, goal stuff is in crates/codegen/xai-grok-shell/src/session/goal_*.rs.

+1

Still not implemented? we need this /goal

This feature is indeed very necessary. Currently, I am working on a project where I need to repeatedly send repetitive dialogues for the Agent to perform certain tasks. With the /loop or /goal commands, it will significantly reduce the time I spend manually operating.

Not sure if it's helpful to anyone, but I've been migrating to codex.
There's a project called opencodex that lets you use your opencode go subscription (or any subscription) in codex. Any model you want.
Still not perfect - the sandboxing is a bit buggy, but has all the features I need, including goal and automations.

lets get this in bois

Do not +1 github threads. Leave a 👍 react, subscribe, and wait.

Please add /goal its much needed

Why isn't there a /goal command in opencode yet? It's the main reason I switch away to other harnesses when I do (despite loving opencode).

Hi everyone,

I’ve been working on this @bojackduy/opencode-loopd as a plugin-based implementation that explores much of the same problem space discussed in this issue.

opencode-loopd implements a persistent goal and continuation engine rather than a prompt-only /goal command. The current implementation includes:

Persistent goal state
Automatic continuation when a worker session becomes idle
Pause, resume, clear, and steering controls
Turn, failure, no-progress, and timeout limits
Explicit progress and completion tools available to the worker
Optional shell-based verification before accepting completion
Dedicated child sessions for background goals
Multiple goals that can run independently while the parent session remains interactive

The main architectural difference is that opencode-loopd models a goal as a managed background worker session, rather than attaching the goal directly to the current OpenCode session.

I do not consider this a replacement for a native implementation. A core implementation still has important advantages that a plugin cannot fully provide, including:

Canonical server-side goal state
Official HTTP and SDK APIs
Shared state across TUI, desktop, and other clients
Runtime-owned lifecycle and accounting semantics
A stable goal primitive that other OpenCode integrations can depend on

That said, I wanted to share the project here because it may be useful as a working experiment and as prior art for some of the lifecycle, continuation, verification, and UX questions involved in this feature.

Repository: https://github.com/bojackduy/opencode-loopd
npm: https://www.npmjs.com/package/@bojackduy/opencode-loopd

I would particularly appreciate feedback on the trade-offs between the background child-session model used by opencode-loopd and the goal-attached-to-current-session model proposed here.

If any parts of the implementation or design are useful for the native feature, I’d also be happy to discuss them or contribute relevant ideas upstream.

Can really use opencode without /goal command (but codex and claude have it and it is a must)

Hey, got a working plugin for this. Tested with gpt-4o, zero core changes.

Two tools: goal (set/status/clear) and loop (add/list/remove).
State in .opencode/harness/. Slash commands /goal, /goal-status, /loop.

Compared to open PRs:

#45379 (thdxr) - core implementation with auto-continuation. Ours is a plugin SDK example, no core changes. Different scope.

#28610 (closed) - auto-continuation via idle events. Ours does not do that. User drives with slash commands.

#32743 (draft) - SQLite + core runtime. Ours is just file-based state.

@bojackduy/opencode-loopd - full production plugin with subagents, TUI dashboard, scheduled goals. It's more mature as as a production goal engine (1000+ lines vs our ~90). Mine is just a simple addition for monitoring/retrying tasks here etc.

	Our plugin	opencode-loopd
Lines	~90	1000+
Auto-continuation	No	Yes
Subagents	No	Yes
TUI dashboard	No	Yes
Scheduled goals	No	Yes
State	Simple JSON	Complex + artifacts
License	MIT	AGPL-3.0
Purpose	Example plugin	Production tool

Free models work because the slash command injects a prompt telling the agent to call the tool. No tool-calling needed from the model side.

PR: #46328

@charleneleong-ai

@charleneleong-ai does your PR allow goal instructions to control turn like claude/codex does by for example writing "one task per turn" or "max 20 turns" ?

@mmcedora

@charleneleong-ai does your PR allow goal instructions to control turn like claude/codex does by for example writing "one task per turn" or "max 20 turns" ?

Hello @mmcedora, yes I've added that here now

Is there any update on the related PR, and when might it be reviewed and merged?

Also, once this feature is implemented, will it work through OpenCode’s ACP integration as well, including when OpenCode is used as an external agent in Zed? Since OpenCode already supports ACP and Zed runs OpenCode through opencode acp, it would be useful to know whether the goal lifecycle and controls will also be available through ACP.

Related discussion: zed-industries/zed#63228

@thdxr

thdxr merged #45379 (autonomous /goal) at 2026-09-18 20:59 UTC; #49866 reverted it at 23:14 UTC with only "Requested by: @thdxr (dax via Slack)". I can't find a public reason and I'm not going to guess at one — asking instead.

Two things from reading the code that seem relevant to why this is hard to get right:

Cancel authority is the part that breaks. #48239 documents the round driver re-claiming on cancel — "the stop button does not stop the loop". A goal loop the user can't stop is worse than no goal loop, so pause has to abort the in-flight turn, not just disarm the next one.

The desktop has nowhere to show goal state. A goal that lives only in the transcript is invisible to whoever set it. DSH keeps paused | blocked | complete and separates process-local activation from durable phase; ZCode shows objective + elapsed in a card and refuses to mark complete while a to-do is unfinished.

Would a plugin surface be acceptable? I can contribute just the indicator for the desktop composer area (session-composer-region.tsx) on its own, with the loop logic behind it.

Happy to close this if it's still not planned — nexxeln's "not planned as of yet" was five months ago.

v2 and still no goals, good lord that i still use pi.

Any news on this?

I'm still using opencode-goal-plugin, it is compatible with OpenCode v2, but broken sometimes. Tolerably.

There are four PRs open that add this natively — the durable goal/todo contracts (#54799), the endpoints and /goal command (#55744), the indicator and todo dock (#56417), and the round driver with an independent verifier (#56450). They are in review; none has merged yet.

Until they land, a plugin is the workaround.

Upstream now has this: #59437 landed a /goal command with a client-side completion check. That closes the user-facing request here, so I closed the four PRs I had open for an alternative implementation (#54799, #55744, #56417, #56450) rather than leave a second /goal competing with it.

Recording what that branch explored, in case any of it is useful later:

Durable goal state. The goal lived in session_goal/session_todo as projections of four durable events, with a revision compare-and-set on updates, so a restart resumed the same goal and clients derived it from the event log rather than from plugin storage.
Round budget where rounds are admitted. The count advanced in the session.inbox.enqueued projection of the synthetic round message, not from verifier verdicts, so a verifier that publishes nothing still cannot loop past maxGoalRounds.
Independent verification. A separate model call judged the todo list, and a complete verdict only landed when every item was settled and the list was non-empty.

None of that is a request — the current implementation works without it. It is here because the two failure modes it hardens against (goal state lost on restart, and a silent verifier turning into an unbounded loop) are the ones that showed up while building it.

Navigation Menu

Repository navigation

[FEATURE]: Add native session goals with /goal #27167

Feature hasn't been suggested before.

Describe the enhancement you want to request

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE]: Add native session goals with /goal #27167

Description

Feature hasn't been suggested before.

Describe the enhancement you want to request

Activity

ZeroPointSix commented on May 23, 2026

uid13 commented on May 23, 2026

Presmanes3 commented on May 23, 2026

VennDev commented on May 23, 2026

ICT-Vision-BE commented on May 23, 2026

andresj-sanchez commented on May 24, 2026

AustinM731 commented on May 24, 2026

thecoooler commented on May 25, 2026

endlessblink commented on May 25, 2026

forMwish commented on May 26, 2026

NathanKong76 commented on May 27, 2026

zirui commented on May 28, 2026

fengnan23 commented on May 29, 2026

vineye25 commented on May 29, 2026

diederik-vink commented on May 29, 2026

alexeygrigorev commented on May 30, 2026

mglenjoy1 commented on Jun 3, 2026

shensheng-kuang commented on Jun 4, 2026

wcldyx commented on Jun 4, 2026

aalfath commented on Jun 5, 2026

furkancak1r commented on Jun 5, 2026

KillianGDK-FDTI commented on Jun 8, 2026

chairulridjaal commented on Jun 8, 2026

shrey16 commented on Jun 9, 2026

srjustice commented on Jun 10, 2026

TopProjectsCreator commented on Jun 11, 2026

Alino commented on Jun 11, 2026

wuaishare commented on Jun 11, 2026

wzj-zz commented on Jun 11, 2026

luciengeorge commented on Jun 11, 2026

gandazhi commented on Jun 12, 2026

faetschi commented on Jun 12, 2026

mishl-dev commented on Jun 14, 2026

SimSonic commented on Jun 15, 2026

mugnimaestra commented on Jun 16, 2026

bruntonandy commented on Jun 16, 2026

AshutoshGitMirror commented on Jun 19, 2026

1337Core commented on Jun 22, 2026

dvnold commented on Jun 23, 2026

dvnold commented on Jun 23, 2026

jamhour1g commented on Jun 25, 2026

zhangp365 commented on Jul 1, 2026

0xkeenz commented on Jul 3, 2026

puzanov commented on Jul 5, 2026

dvnold commented on Jul 6, 2026

sharkisyou commented on Jul 15, 2026

greatbody commented on Jul 16, 2026

Alino commented on Jul 16, 2026

06kellyjac commented on Jul 16, 2026

faetschi commented on Jul 16, 2026

toonvank commented on Jul 28, 2026

vielhuber commented on Jul 29, 2026

snailwei commented on Aug 4, 2026

xiaoxustudio commented on Aug 8, 2026

ianldgs commented on Aug 8, 2026

lumen-rot commented on Aug 11, 2026

forresthopkinsa commented on Aug 19, 2026

haseeb-heaven commented on Aug 21, 2026

SPRIME01 commented on Aug 21, 2026

bojackduy commented on Aug 23, 2026

mmc41 commented on Aug 26, 2026

charleneleong-ai commented on Aug 31, 2026

mmcedora commented on Aug 31, 2026

charleneleong-ai commented on Sep 3, 2026

muhammad-fiaz commented on Sep 19, 2026

Te-River commented on Oct 11, 2026

DarkReaperBoy commented on Oct 11, 2026

skhaz commented on Oct 17, 2026

SimSonic commented on Oct 18, 2026

Te-River commented on Oct 19, 2026

Te-River commented on Oct 31, 2026

Metadata

Metadata

Assignees

Labels