[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.

This issue might be a duplicate of existing issues. Please check:

[FEATURE]: Add native session goals with /goal #27162: Identical feature request — same title, description, and author. This appears to be a repost of that issue.

+1

Using /goal in codex, find it very usefull.

any update on this feature ? we need it in opencode.

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

@nexxeln

@nexxeln I'd say that anything to achieve feature parity with the main harnesses (codex/claude) will probably help big time with adoption. It makes me consider switching to codex because of that, automations, computer use, first-class remote control from my phone, etc.

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

We need /goal

@nexxeln

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

/goal is a good built-in loop to have, models keep skipping stuff and need too much hand holding for larger tasks

codex, claude code, hermes, all added it, opencode should not be sleeping.

we def need /goal +1

+1 We need native support for /goal, TUI, Desktop, and WebUI. Thanks a lot for all the contributions from the community and the OpenCode team. This is an incredible product, and I wish you all the best.

+1

Yes we need

bump this

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

61 remaining items

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

github-actions commented on May 12, 2026

bigben446 commented on May 15, 2026

Cinerar commented on May 16, 2026

anhalu commented on May 17, 2026

nexxeln commented on May 18, 2026

ianldgs commented on May 19, 2026

trainliang commented on May 19, 2026

n2k3 commented on May 19, 2026

Alino commented on May 19, 2026

kleozzy commented on May 21, 2026

greatbody commented on May 22, 2026

PAMinerva commented on May 22, 2026

mikeldev0 commented on May 22, 2026

old-mikser commented on May 23, 2026

61 remaining items

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

Type

Projects

Milestone

Relationships

Development

Issue actions