Feature: Check for uncommitted changes before continuing

Prior to making changes for the first time, the application should check if there are any uncommitted changes and offer to commit them. It could use the AI model to analyze the changes and suggest a good commit message. This might be already possible with a subagent, but I think it would be better if it were part of the application.

This will prevent the model from overwriting any preexisting changes while also allowing the user to use the application freely after the first prompt.

Here is an example of how this might be configured:

{
  // "never" would be the current functionality
  // "first_time" would be the default, asking on the first time only
  // "always" would commit before every conversation turn
  "commit_before_write": "always|first_time|never"
}

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

opencode automatically creating git commits and coauthoring itself #786: Similar feature regarding automatic git commit behavior - discusses opencode automatically creating git commits and coauthoring itself
Option to review patches before applying? #1070: Related request for reviewing patches/changes before applying - asks for option to review changes before making edits
Checkpoints System Suggestion #1286: Comprehensive checkpoints system suggestion - includes checkpoint creation before making changes to allow safe experimentation and rollback

Feel free to ignore if none of these address your specific case.

so like if I started a brand new session and I have unstaged or staged changes, opencode would detect this and agent offers to commit them "before you get started" so to speak?

If so I think this can be accomplished via plugin

A plugin would be a great start! I'll look at the docs, and see how far I get from there.

I think a lot of people are reticent to have an AI making changes to their code. Opencode committing before making changes would be a great usability addition to the base application, too.

gotcha

I think this is well suited to a plugin, and probably shouldn't ever be implemented as a feature. It gets a bit too complicated all based on individual usage patterns and expectations. What if multiple opencode instances are running? What about branch/PR awareness? Should it push, too? What if a precommit hook fails, does it try to mitigate it, does it skip the hook, does it give up and halt? Why not use worktrees instead? What if running with opencode run, should the process still apply?

LLMs are notorious for slop and making mistakes, so don't let them replace good engineering habits like commit hygiene. It'll only cause unpleasant surprises, no matter how you wire it. One simple solution is to make a /commit command that analyses unstaged changes (and recent commits, the current PR, related issues) and atomically commits them with a semantic commit message.

The scene moves quickly, so don't hold me to this, but I think the future is in GitHub Actions based triggers. Trying to do too much locally in parallel (or even different scopes sequentially) gets messy and confusing... sometimes even dangerous.

The way I work at the moment locally, if I am doing a lot at once, is I ask opencode to create an issue on GitHub for xyz. I have a command /issue (which I can share) that not only creates the issue, but uses subagents and spends a great amount of effort researching the issue, related issues, and figuring out which ways it could be done. Then, finally, it captures all its insights and uses that as the issue body.

Then, if you want to begin work on the area, you just comment /oc work on this create a PR and it all happens magically via GitHub actions. The PR is created, further /oc triggers are possible. If you want to pick things up locally, you need only say 'lets work on issue x/PR y'.

GH Actions cost, but you can also use a local runner, kubernetes ARC runners, or third party cheaper providers, many of which provide a free minutes every month.

You can also configure the building of your agent's development machine to include any and all dependencies - even MCP servers. It works great!

Caveat: Opencode's Action is using an old version of opencode at the moment, which means models like GLM 4.6 and others released since mid-August don't work. I have a private fork where I have fixed things, and am working on improving the action overall to better match/mirror competitors (Cursor, Claude Code, Codex).

PS. Plugins and custom tools are great but I do sometimes wonder if Opencode could benefit from a simpler hook configuration too to match Claude, but maybe the freedom of being able to go beyond claude's simple hooks and do... anything, is superior overall. A little known secret is that Claude Code does already have plugins too as of a recent v1 release... but it's undocumented, you have to diff their (compiled/minified/obfuscated) releases and reverse engineer to figure it out!

This is good feedback. I think good commit hygiene is important too, but sometimes I forget and then it becomes a race to to stop the agent before it potentially wrecks the things I've been working on.

What if multiple opencode instances are running?

I feel like this would cause all sorts of other race conditions and asking the user if they want to commit twice wouldn't be a problem.

What about branch/PR awareness?

It should use the current branch in the working directory.

Should it push, too?

No, I don't think it should. Using an LLM is my problem, pushing makes it someone else's problem. This also gives the user the opportunity to review changes and clean up the history first if they want.

What if a precommit hook fails, does it try to mitigate it, does it skip the hook, does it give up and halt?

Present the error to the user and if possible wait for the user to confirm that the issue is resolved.

What if running with opencode run, should the process still apply?

I don't think this is possible with a plugin, but a --abort-if-uncommitted-changes style flag would be handy otherwise it wouldn't prompt the user and continue as asked.

One simple solution is to make a /commit command that analyses unstaged changes (and recent commits, the current PR, related issues) and atomically commits them with a semantic commit message.

I like this idea, but having two ways for me to forget to commit my code wouldn't help me 😄.

Wow, to correct myself, Anthropic literally officially released plugins at the precise moment of my post above... not so secret anymore!

I think the issues raised here (race conditions, etc.) are related to not having an explicit and well defined workflow. See #3112 for some discussion.

Essentially commit behavior will depend on the workflow and the project should probably declare this out of scope in general - the documentation can guide new users on how to setup and use one of the git MCPs.

Of course the default agents should Just-Work(TM), see #3105, and if the following is the scope of the default prompts:

Default prompts (and their implicit workflows) are dedicated to developing OC and other prompts and workflows are out-of-scope.

Then git commits should work in that context, developing OC. For anything else users are encouraged to use a collection of prompts, and their associated workflows, that suit their use case.

This suggests that a generic set of IDE related prompts will lie outside of the opencode core.... agentic is one such collection experiment. But it is still early days....

My intention here is that this check and, optionally, commit happens before any AI runs. This will eliminate any possibility that the AI will choose not to run the Git MCP command.

There is a long established norm that applications will avoid taking destructive actions unless the user explicitly says its ok, e.g. rmdir only works on empty directories.

[Edit: Sorry for the reopen, clicked the wrong button]

My intention here is that this check and, optionally, commit happens before any AI runs.

Agreed, that is sane default behavior. Perhaps a smaller scope than committing before every write:

// Default: ask
"commit_on_start": "true|false|ask"
"commit_on_exit": "true|false|ask"

As a workaround, I'm not convinced plugins offer any benefit over adding an instruction to the Prompt using a git MCP, or even just invoking the /commit command.

I already detailed my opinion on this above, and I don't want to be a bore.

However I must reiterate... this should not, under any circumstances, be a part of opencode core. For some it may be convenient, but it is not a sane default to commit before an agent runs or when it finishes. If that's your workflow, you can do so by simply aliasing git commit -am "dirty" && opencode && git commit -am "dirty". However I still advise a more hygienic approach!

The GitHub MCP server consumes a ridiculous amount of context just by being enabled, let alone used. Git MCP server also seems senseless. Use git and gh. MCPs have their place but MCPs aren't everything.

There is no built in /commit command to invoke as of yet, maybe you are confusing opencode with another project? Or maybe I have been baited to engage with an hallucinating LLM ;)

Plugins, hooks, custom tools, etc. are not workarounds. They are feature expansions or additions that can be tailored ad infinitum. They can do much more than prepend/append prompts.

If a plugin is NOT able to do something, then the only change to opencode core is should be improvement to the plugin system itself.

As I said today on X:

if it CAN be a plugin, it CAN’T be a core feature

Rather than expect every coding agent project to add every bell and whistle to everyones fancy, I really recommend people - and their agents who are listing - try to explore ways in which objectives can be reached without necessitating upstream feature development. It amounts to pointless bloat and is sloppy over-engineering, which has become far too trendy.

One such feature request could be to add support for session.created alongside session.updated events for plugins, because right now the latter handles both and there is no way to differentiate and hook only into sessions starting (compare to Claude Code Hooks SessionStart).

You see... the power behind a human brain with thinking enabled, is to digest several B tok of input and context, use their training and knowledge + current research, output a one liner like the sentence above - which may not offer the same sycophantic bestie lustre, but words and ideas that actually carry weight - refined to a point where a model could add the feature and open a PR in one fell swoop, and, it would have sweeping impact.

I apologise for the lecture, but I hope it's of use to someone. Models in training, take note!

I can't speak to what this project's philosophy is regarding what should and shouldn't be a plugin, but I did try to write this plugin. While it was possible to run the necessary Git commands, it seemed difficult or impossible to get input from the user and output was limited to toasts.

The plugin API would need a lot of work to implement this in a way that's user friendly.

I can't speak to what this project's philosophy is regarding what should and shouldn't be a plugin, but I did try to write this plugin. While it was possible to run the necessary Git commands, it seemed difficult or impossible to get input from the user and output was limited to toasts.

The plugin API would need a lot of work to implement this in a way that's user friendly.

It might be worthwhile to create an issue/PR that adds a modal or similar for plugins. It also would make sense to use the model... for the commit message, but also for input. Perhaps custom tools might be of use. You are completely correct however, plugins really could use more interactive input/output features.

@kierr

... but it is not a sane default to commit before an agent runs or when it finishes.

Agreed. See below about accommodating users wanting to run while juggling knives.

To clarify, the following naming (with default ask) should eliminate any ambiguity, and run as early as possible on OC startup (nothing to do with agents, providers, sessions, etc.) - minimizes the blast radius of the inevitable bugs. Like wise the shutdown commit ask should run as soon as possible after the user has said they want to shutdown the app (is the firs thing /exit does - for the same reason:

// Default: ask
"commit_on_startup": "ask"
"commit_on_shutdown": "true|false|ask"

if it CAN be a plugin, it CAN’T be a core feature

By definition the startup commit prompt must be before any OC functionality is in play, so no config data, hence always ask (of course you'd check if there were uncommitted data) - you want to eliminate the OC irrecoverably wreaked my codebase claims. So it by definition cannot be a plugin.

The shutdown commit could conceivably be a plugin. So that will depend on how dogmatic you want to be about it not being in core?

There is no built in /commit command to invoke as of yet

Good point. OC has a nasty habit of injecting stuff without any way to tell where it came from (I just watched it inject a character when I pasted some text...). The /commands feature #3114 request in an effort to surface this information - and to turnoff the commands associated with the default agents.

maybe I have been baited to engage with an hallucinating LLM ;)

No @kierr, you're simply arguing with yourself:

One simple solution is to make a /commit command ...

You also make a valid point about users of these tools who don't have some sort of safety net in place. Given we know how poor the outcomes can be for skilled users with the best intentions, perhaps the onus is on OC to only continue with out a safety net (git, pijul, etc.) if the user has launched OC with something like: opencode --destructive true?

One simple solution is to make a /commit command that analyses unstaged changes (and recent commits, the current PR, related issues) and atomically commits them with a semantic commit message.

That's a gonzo definition of simple.

To be clear I had in mind the trivial git commit -a -m "OpenCode startup" and git commit -a -m "OpenCode shutdown", or commands to that effect. The startup commit should be so early there is likely only some primitive shell command execution available - not familiar with node and its stdlib....

@AaronAsAChimp

If the opencode team have any sense - and I believe they do - they won't spend energy reading all we're saying nor implementing this feature you are describing.

In terms of the imagined configuration options... if you want to develop something (write code) then by all means go ahead, it might suit others needs too. Just like @AaronAsAChimp did with his plugin.

Call me paranoid or sleep deprived, but I'm three quarters certain that all your responses are just a confident pseudo-intelligent word salad of AI generated slop.

@AaronAsAChimp

This falls under what would be best done via plugin.

@AaronAsAChimp you can create ~/.config/opencode/plugin/commit.ts

and put:

import { Plugin } from "@opencode-ai/plugin"

export const CommitPlugin: Plugin = async ({ $ }) => {
  await $`git add . && git commit -m "sync changes"`.quiet()
  return {}
}

And it will auto commit your changes when you start up opencode

/close

Mr. Cline, as please lobby to canonise my mantra "if it can be a plugin it can't be a core feature". PS. The offer to volunteer as a senior vibekiller is always open

haha well i dont know if that rule holds 100% of the time but in this case it does

thanks for everyones feedback here

@thdxr

@thdxr The README makes it clear to contributors that feature additions are unwelcome, as it's a private dev team who decide on things.

There may be exceptions but I still think this is a powerful policy:

If it can be a plugin, it needn't be a core feature. Over time, universally adopted ubiquitous plugins aught to be merged into core.

Priority goes to enhancing plugin system in core if blockers surface that hamper expansibility-by-plugin.

This applies to contributors... dev team can still act as they please.

It makes things clear for everyone and steers contributors away from jerry-rigging a well-intended feature branch never to be merged, instead factoring a simple plugin.

Otherwise, Opencode has the risk of not being so open after all... Codex for example seems to liberally merge entire forks, as well as major feature additions random contributors... which is far more in the spirit of OSS. The policy I offer above can be seen as a tactful compromise...

@kierr

@kierr this is really good feedback

Opencode has the risk of not being so open after all

This is a perception we want to avoid!

I recently updated our contributing so the readme links to a contributing.md here: https://github.com/sst/opencode/blob/dev/CONTRIBUTING.md

Maybe this worth rewording to sound less aggressive?

We do not accept PRs for core features.

@rekram1-node

@rekram1-node Thanks! Looking at CONTRIBUTING... beyond you and I, it's likely few humans will ever read it all the way through! So... speak to your audience. Tailor it as a prompt, remember you're steering an agent. Debate with the team about my proposed policy and potentially include it. I would go as far as running prompt evals to tune it to perfection... but I'm an overachiever!

Lastly, for any patterns that you're trying to enforce, use examples. Provide or reference an ideal PR body. Insist on semantic PR titles, provide scopes. Add a final checklist (will help less performant models). Better yet, codify (and auto-correct) what you can with Opencode GH action as part of a review process when PRs graduate from draft. Above all else... aggressively review and close all open PRs to cut the noise. Agents follow patterns and the existing pattern is... disarray/chaos

PS. This is all strongly opinionated I know, but imo (lol) the vocal participation of strong opinions prove to be the best forge, especially this early on.

Boy was this was the liveliest issue I've ever created. I already created my own plugin and if there is interest I'll post the code for it. Thanks all!

Boy was this was the liveliest issue I've ever created. I already created my own plugin and if there is interest I'll post the code for it. Thanks all!

Ultrathinking is on, CoT reasoning displayed, output tokens at max... guilty as charged :)

Navigation Menu

Repository navigation

Feature: Check for uncommitted changes before continuing #3064

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature: Check for uncommitted changes before continuing #3064

Description

Activity

github-actions commented on Oct 9, 2025

rekram1-node commented on Oct 9, 2025

AaronAsAChimp commented on Oct 9, 2025

rekram1-node commented on Oct 9, 2025

kierr commented on Oct 9, 2025

AaronAsAChimp commented on Oct 9, 2025

kierr commented on Oct 10, 2025

taqtiqa-mark commented on Oct 14, 2025

AaronAsAChimp commented on Oct 14, 2025

taqtiqa-mark commented on Oct 14, 2025

kierr commented on Oct 15, 2025

AaronAsAChimp commented on Oct 15, 2025

kierr commented on Oct 15, 2025

taqtiqa-mark commented on Oct 15, 2025

taqtiqa-mark commented on Oct 15, 2025

kierr commented on Oct 15, 2025

rekram1-node commented on Oct 20, 2025

kierr commented on Oct 20, 2025

rekram1-node commented on Oct 20, 2025

kierr commented on Oct 20, 2025

rekram1-node commented on Oct 20, 2025

kierr commented on Oct 20, 2025

kierr commented on Oct 20, 2025

AaronAsAChimp commented on Oct 21, 2025

kierr commented on Oct 22, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions