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_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗