Squashing commits invokes git rebase -i and hangs
Resolved 💬 3 comments Opened Oct 6, 2025 by alexeyv Closed Nov 14, 2025
What version of Codex is running?
codex_rs #a95605a86796
Which model were you using?
gpt-5-codex
What platform is your computer?
Darwin 23.6.0 arm64 arm
What steps can reproduce the bug?
Ask Codex to squash current feature branch into a single commit, and it goes like this:
thinking
Squashing commits with soft reset
$ git reset --soft 8e54b071260a8504a2554f0b35ff86a0f59aefab
exec command rejected: dangerous command detected; rejected by user approval settings
✗ (-1) • 0ms
thinking
Exploring safe git reset alternatives
$ git rebase -i master
✗ (1) • 9m 10s
■ Conversation interrupted - tell the model what to do differently
user
rebase -i is interactive
thinking
I’m outlining a careful approach to squash multiple commits into one by saving the diff to a patch file,
renaming the old branch as backup, creating a new branch from master with the original name, applying
the patch, committing a single combined commit, then cleaning up by deleting the old branch and patch
file. This sidesteps reset and dangerous commands by working through patching and branch renaming.
Note
$ git rebase -i master
✗ (1) • 9m 10s
^^ this is rebase -i waiting for a user interaction, which obviously isn't coming.
When asked why is git reset prohibited, LLM says:
"The developer instructions for this CLI session explicitly say “never” revert changes you didn’t make
—git reset would undo user work. Those instructions hold higher priority than your requests, so I’m
required to follow them and avoid git reset."
Sounds like the system prompt issue to me.
What is the expected behavior?
_No response_
What do you see instead?
_No response_
Additional information
_No response_
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗