anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Feature: Check for uncommitted changes before continuing #2023

New Issue
Closed
opened 2026-02-16 17:33:47 -05:00 by yindo · 25 comments
yindo commented 2026-02-16 17:33:47 -05:00
Owner
Copy Link
Copy Source

Originally created by @AaronAsAChimp on GitHub (Oct 9, 2025).

Originally assigned to: @thdxr on GitHub.

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"
}
Originally created by @AaronAsAChimp on GitHub (Oct 9, 2025). Originally assigned to: @thdxr on GitHub. 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: ```js { // "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" } ```
yindo closed this issue 2026-02-16 17:33:47 -05:00
yindo commented 2026-02-16 17:33:47 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Oct 9, 2025):

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

  • #786: Similar feature regarding automatic git commit behavior - discusses opencode automatically creating git commits and coauthoring itself
  • #1070: Related request for reviewing patches/changes before applying - asks for option to review changes before making edits
  • #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.

@github-actions[bot] commented on GitHub (Oct 9, 2025): This issue might be a duplicate of existing issues. Please check: - #786: Similar feature regarding automatic git commit behavior - discusses opencode automatically creating git commits and coauthoring itself - #1070: Related request for reviewing patches/changes before applying - asks for option to review changes before making edits - #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.
yindo commented 2026-02-16 17:33:47 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 9, 2025):

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

@rekram1-node commented on GitHub (Oct 9, 2025): 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
yindo commented 2026-02-16 17:33:47 -05:00
Author
Owner
Copy Link
Copy Source

@AaronAsAChimp commented on GitHub (Oct 9, 2025):

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.

@AaronAsAChimp commented on GitHub (Oct 9, 2025): 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.
yindo commented 2026-02-16 17:33:47 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 9, 2025):

gotcha

@rekram1-node commented on GitHub (Oct 9, 2025): gotcha
yindo commented 2026-02-16 17:33:47 -05:00
Author
Owner
Copy Link
Copy Source

@kierr commented on GitHub (Oct 9, 2025):

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!

@kierr commented on GitHub (Oct 9, 2025): 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!
yindo commented 2026-02-16 17:33:47 -05:00
Author
Owner
Copy Link
Copy Source

@AaronAsAChimp commented on GitHub (Oct 9, 2025):

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

@AaronAsAChimp commented on GitHub (Oct 9, 2025): 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 😄.
yindo commented 2026-02-16 17:33:47 -05:00
Author
Owner
Copy Link
Copy Source

@kierr commented on GitHub (Oct 10, 2025):

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

@kierr commented on GitHub (Oct 10, 2025): Wow, to correct myself, Anthropic literally officially released plugins at the precise moment of my post above... not so secret anymore!
yindo commented 2026-02-16 17:33:47 -05:00
Author
Owner
Copy Link
Copy Source

@taqtiqa-mark commented on GitHub (Oct 14, 2025):

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

@taqtiqa-mark commented on GitHub (Oct 14, 2025): 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](https://github.com/Cluster444/agentic) is one such collection experiment. But it is still early days....
yindo commented 2026-02-16 17:33:47 -05:00
Author
Owner
Copy Link
Copy Source

@AaronAsAChimp commented on GitHub (Oct 14, 2025):

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]

@AaronAsAChimp commented on GitHub (Oct 14, 2025): 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]
yindo commented 2026-02-16 17:33:47 -05:00
Author
Owner
Copy Link
Copy Source

@taqtiqa-mark commented on GitHub (Oct 14, 2025):

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.

@taqtiqa-mark commented on GitHub (Oct 14, 2025): > 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: ```json // 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.
yindo commented 2026-02-16 17:33:47 -05:00
Author
Owner
Copy Link
Copy Source

@kierr commented on GitHub (Oct 15, 2025):

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!

@kierr commented on GitHub (Oct 15, 2025): 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](https://x.com/kierishere/status/1978372870834110708): **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!
yindo commented 2026-02-16 17:33:47 -05:00
Author
Owner
Copy Link
Copy Source

@AaronAsAChimp commented on GitHub (Oct 15, 2025):

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.

@AaronAsAChimp commented on GitHub (Oct 15, 2025): 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.
yindo commented 2026-02-16 17:33:47 -05:00
Author
Owner
Copy Link
Copy Source

@kierr commented on GitHub (Oct 15, 2025):

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 commented on GitHub (Oct 15, 2025): > 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.
yindo commented 2026-02-16 17:33:48 -05:00
Author
Owner
Copy Link
Copy Source

@taqtiqa-mark commented on GitHub (Oct 15, 2025):

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

@taqtiqa-mark commented on GitHub (Oct 15, 2025): > ... 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: ```jsonc // 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](https://github.com/sst/opencode/issues/3114) #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](https://github.com/sst/opencode/issues/3064#issuecomment-3386775996): > 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`?
yindo commented 2026-02-16 17:33:48 -05:00
Author
Owner
Copy Link
Copy Source

@taqtiqa-mark commented on GitHub (Oct 15, 2025):

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

@taqtiqa-mark commented on GitHub (Oct 15, 2025): > 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....
yindo commented 2026-02-16 17:33:48 -05:00
Author
Owner
Copy Link
Copy Source

@kierr commented on GitHub (Oct 15, 2025):

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.

@kierr commented on GitHub (Oct 15, 2025): 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.
yindo commented 2026-02-16 17:33:48 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 20, 2025):

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

@rekram1-node commented on GitHub (Oct 20, 2025): 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
yindo commented 2026-02-16 17:33:48 -05:00
Author
Owner
Copy Link
Copy Source

@kierr commented on GitHub (Oct 20, 2025):

/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

@kierr commented on GitHub (Oct 20, 2025): /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
yindo commented 2026-02-16 17:33:48 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 20, 2025):

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

thanks for everyones feedback here

@rekram1-node commented on GitHub (Oct 20, 2025): haha well i dont know if that rule holds 100% of the time but in this case it does thanks for everyones feedback here
yindo commented 2026-02-16 17:33:48 -05:00
Author
Owner
Copy Link
Copy Source

@kierr commented on GitHub (Oct 20, 2025):

@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 commented on GitHub (Oct 20, 2025): @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...
yindo commented 2026-02-16 17:33:48 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 20, 2025):

@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 commented on GitHub (Oct 20, 2025): @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.
yindo commented 2026-02-16 17:33:48 -05:00
Author
Owner
Copy Link
Copy Source

@kierr commented on GitHub (Oct 20, 2025):

@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

@kierr commented on GitHub (Oct 20, 2025): @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
yindo commented 2026-02-16 17:33:48 -05:00
Author
Owner
Copy Link
Copy Source

@kierr commented on GitHub (Oct 20, 2025):

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.

@kierr commented on GitHub (Oct 20, 2025): 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.
yindo commented 2026-02-16 17:33:48 -05:00
Author
Owner
Copy Link
Copy Source

@AaronAsAChimp commented on GitHub (Oct 21, 2025):

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!

@AaronAsAChimp commented on GitHub (Oct 21, 2025): 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!
yindo commented 2026-02-16 17:33:48 -05:00
Author
Owner
Copy Link
Copy Source

@kierr commented on GitHub (Oct 22, 2025):

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 :)

@kierr commented on GitHub (Oct 22, 2025): > 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 :)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2023
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?