gemini-cli 0.1.3: 400 INVALID_ARGUMENT when resuming a saved chat after /chat load
gemini-cli 0.1.3 (OAuth personal auth, Cursor as preferred editor) returns 400 INVALID_ARGUMENT on every prompt after I /chat save, quit, and /chat load a conversation: the history displays, but any prompt fails with "Please ensure that the number of function response parts is equal to the number of function call parts of the function call turn." Pressing Escape twice to interrupt pending tool calls also triggers the same error. Is there a fix or workaround?
Originally asked on GitHub: https://github.com/google-gemini/gemini-cli/issues/1690
5 answers
The issue is closed as COMPLETED, but the thread does not confirm that the proposed fix was merged or which release contains it. A contributor (comment 4) diagnosed the cause and proposed a patch in /packages/cli/src/ui/hooks/slashCommandProcessor.ts: when a saved chat contained function call/response items, the UI displayed them even though they have no displayable text, so the Gemini API received a history where function call parts and function response parts were no longer paired, producing the 400 INVALID_ARGUMENT. The proposed fix keeps all items in the chat history for API compatibility but only displays items that contain text (a hasOnlyText check) so function call/response parts stay in the payload. Since the patch's release is unconfirmed, treat this as an explanation rather than a shipped fix.
Two workarounds worked while the bug was live:
- Copy the entire conversation from the terminal into a text file (e.g. history.txt), start a new gemini-cli session, and tell it to use that file as context to continue where you left off (comment 11).
- In Cursor, ask Gemini 2.5 Pro to locate where gemini-cli stores conversations on disk, copy the crashed conversation into a non-hidden folder, start a new gemini-cli conversation, and @-mention the file so the model reads the previous chat (comment 3).
One reporter (comment 9) hit the same mismatch without save/load: pressing Escape twice to interrupt two pending tool actions made every subsequent prompt fail, so interrupted multi-tool runs are also affected.
General advice: both workarounds write your conversation to local text files; if it contains credentials or secrets, delete those files when you are done with them.
Did this work for you?What a GitHub user tried on GitHub (Didn't work)
Saved the chat with /chat save, quit, restarted gemini, and loaded it with /chat load. The history displayed but every prompt returned the 400 INVALID_ARGUMENT function-response-parts error.
Source: https://github.com/google-gemini/gemini-cli/issues/1690 (opens external site)
Did this work for you?What @KCHIPANACH tried on GitHub (Worked)
Manually copied the entire conversation from the terminal into history.txt, started a new Gemini session, and asked it to use that file as context to continue the conversation.
Did this work for you?What @kayazuko tried on GitHub (Worked)
In Cursor, had Gemini 2.5 Pro find where gemini-cli stores conversations, copied the crashed conversation to a non-hidden folder, then started a new gemini-cli conversation and @-mentioned the file so the model could read the previous chat.
Did this work for you?What @bubosanac tried on GitHub (Outcome unclear)
Reported that pressing Escape twice to interrupt two pending tool actions triggers the same function-response-parts mismatch on every subsequent prompt in the same session.
Did this work for you?
Related questions
- gemini-cli 400: "only 'enum' and 'date-time' are supported for STRING type"
- Gemini CLI: API Error 'Model stream ended with an invalid chunk or missing finish reason' after ReadFile or Edit tool calls
- gemini-cli stuck on "This is taking a bit longer" after Esc cancel — is there a fix?
- Is there a way to get codebase indexing in gemini-cli?
- How can I use voice input instead of typing with Gemini CLI?