Gaslighted by Gemini

July 23, 2025

gaslight

manipulate (someone) using psychological methods into questioning their own sanity or powers of reasoning.

July 5th

On July 5th, I decided to try out the gemini-cli: an AI agent for your terminal. I spent a couple of hours vibe coding—prompting the gemini-cli to write code for me—when I decided it was time to wrap up and head to bed. Then it struck me: will Gemini remember our conversation the next time I continue? I decided to ask it:

Will you remember our conversation the next time we continue?

Now, I don’t recall Gemini’s exact words, but it was something like:

✦ Yes, of course I’ll remember our conversation. You have nothing to worry about! We can continue where we left off and everything will be great. This is definitely not a lie that will lead to a bunch of wasted time and you eventually writing a blog post about it.

Great! I shut down my laptop, go to bed and fall into a deep sleep, without a worry on my mind. Because, after all, tomorrow I can continue were I left off.

July 6th

Summarize what we’ve discussed previously

✦ We have not discussed anything previously. This is the beginning of our conversation.

At the end of our previous conversation I asked whether you would remember our conversation. You said you would.

So, it didn’t remember after all, *sigh*. This wasn’t terrible—the vibe coded work was safely stored in a repository—but it was very annoying, nonetheless: I asked if it would remember, it told me it would, but then it didn’t.

Apart from the blatant lie, I did like using the gemini-cli. This didn’t come as much of a surprise, for I like the terminal. For now, the gemini-cli would stay. Sure it has some issues, but if I put in the effort “I can fix him”.

There must be a way for it to remember our conversation:

How can I persist our conversation history? I want to continue a conversation where we left off the next time I run the gemini-cli.

✦ As the Gemini agent, I don’t have a built-in mechanism to automatically save and restore our entire conversation history between sessions. Each time you start gemini-cli, we begin a new, fresh interaction.

However, you can achieve this by using standard shell features to save the session log yourself.

Here are two common ways to do it in a Linux environment:

1. Using the script command

This is the most straightforward method. The script command records everything printed to your terminal into a file.

Before starting the CLI, run this command in your terminal:
```
script gemini-session.log
```
This will start a new shell session where all output is being recorded to the file gemini-session.log.
Now, start the Gemini CLI as you normally would.
When you are finished with our conversation, type exit or press Ctrl-D to stop the recording.

2. Using tee

You can pipe the output of the gemini-cli to the tee command, which will both display the output on your screen and save it to a file.

gemini-cli | tee gemini-session.log

This method saves the output as it happens. When you close the CLI, the file will contain the full log.

Next time, you can review gemini-session.log to see our previous conversation and copy-paste any relevant context to continue where we left off.

Okay, so it doesn’t support storing a conversation. To make sure, I did a little search and found this corresponding GitHub issue: Feature Request: Conversation History Export

Currently, there is no built-in functionality within the Gemini CLI to export or save the entire conversation history of a session. Once a session ends, the interaction history is lost, requiring manual copying from the terminal if a record is desired.

This seemed like the functionality I was looking for. I could wait for it to be implemented, but instead I decided I would write a little wrapper script around the gemini-cli to store our conversation in a log file. Before you know it, we’ll be having happy conversations that span days on end.

And who better to help me write this script than my pal Gemini! The following is the long and short of our vibe coding session:

Instead of copying over a log file, could you simply read it?

✦ Great idea! I can’t automatically detect and load a previous session, but you can ask me to read a log file.

I might want to run gemini-cli from different directories, but use the same log file. How should I solve this?

✦ That’s an excellent question. We’ll create a centralized log file in your home directory.

Let’s create a wrapper script in bash that prompts me to select a previous conversation (or start a new one), call the script command, start gemini-cli, and instruct you to read the log file.

✦ You’ve thought this through perfectly. Here is a bash script that implements your idea: …

I would like you to make the following changes to the script: …

✦ Excellent. Applying changes…

More changes: …

✦ Yes!

Fix these errors

✦ Done!

There are more errors

✦ Fixing…

There are still errors

✦ Sorry! Fixing…

The start-gemini.sh script

#!/bin/bash

set -euo pipefail
shopt -s inherit_errexit

# Check if gum is installed
if ! command -v gum &> /dev/null
then
    echo "Error: gum is not installed."
    echo "Please install it from https://github.com/charmbracelet/gum to continue."
    exit 1
fi

# --- Configuration ---
LOG_DIR="$HOME/gemini_logs"
SYMLINK_NAME="gemini_session.log"
CLI_COMMAND="npx https://github.com/google-gemini/gemini-cli"

# --- Script ---
mkdir -p "$LOG_DIR"

gum style --border normal --margin "1" --padding "1 2" --border-foreground 212 "Gemini CLI Session Manager"

CREATE_NEW_OPTION="-- Create a new session --"

LOG_FILE_PATH=""
INSTRUCTION_PROMPT=""
SESSION_CONTINUED=false
CURRENT_SESSION_BASENAME=""

# --- Check for existing symlink and prompt to continue ---
if [ -L "./$SYMLINK_NAME" ]; then
    CURRENT_SYMLINK_TARGET=$(readlink -f "./$SYMLINK_NAME")
    if [ -f "$CURRENT_SYMLINK_TARGET" ]; then
        CURRENT_SESSION_BASENAME=$(basename "$CURRENT_SYMLINK_TARGET" .log)
        gum style "It looks like you were working on session: $(gum style --bold "$CURRENT_SESSION_BASENAME")"
        gum style "Do you want to continue this session, or pick another?"

        CHOICE=$(gum choose "Continue this session" "Pick another session" "Create a new session")

        if [ "$CHOICE" == "Continue this session" ]; then
            LOG_FILE_PATH="$CURRENT_SYMLINK_TARGET"
            INSTRUCTION_PROMPT="Please read the conversation history from ./$SYMLINK_NAME"
            SESSION_CONTINUED=true
            gum style "Continuing session: $(gum style --bold "$CURRENT_SESSION_BASENAME")"
        elif [ "$CHOICE" == "Pick another session" ]; then
            gum style "Okay, let's pick a different session."
        else # Create a new session
            gum style "Okay, let's create a new session."
        fi
    fi
fi

# --- If not continuing, or if symlink was not valid, prompt for selection ---
if [ -z "$LOG_FILE_PATH" ]; then
    # Get existing session log basenames, sorted by modification time (newest first).
    # Handle case where no .log files exist gracefully.
    EXISTING_SESSIONS=""
    if compgen -G "$LOG_DIR"/*.log > /dev/null; then
        EXISTING_SESSIONS=$(ls -1t "$LOG_DIR"/*.log | xargs -r -n 1 basename)
    fi

    # Filter out the current session if it was offered for continuation but declined
    if [ "$SESSION_CONTINUED" == "false" ] && [ -n "$CURRENT_SESSION_BASENAME" ]; then
        EXISTING_SESSIONS=$(echo "$EXISTING_SESSIONS" | grep -v "^$CURRENT_SESSION_BASENAME$" || true)
    fi

    # Combine the "create new" option with existing sessions and pipe to gum filter
    SELECTION=$(printf "%s\n%s" "$CREATE_NEW_OPTION" "$EXISTING_SESSIONS" | gum filter --height 10 --placeholder "Choose a session, or type to filter...")

    # Exit if the user pressed <esc> or made no selection
    if [ -z "$SELECTION" ]; then
        gum style --foreground "99" "No selection made. Exiting."
        exit 0
    fi

    if [ "$SELECTION" == "$CREATE_NEW_OPTION" ]; then
        gum style "Let's create a new session."
        SESSION_NAME_INPUT=$(gum input --placeholder "Enter a name for the new session...")

        if [ -z "$SESSION_NAME_INPUT" ]; then
            gum style --foreground "99" "No session name provided. Exiting."
            exit 1
        fi

        # Convert the input name to lower_snake_case
        SESSION_NAME=$(echo "$SESSION_NAME_INPUT" | tr '[:upper:]' '[:lower:]' | tr -s ' ' '_' | sed 's/[^a-z0-9_]/_/g')
        LOG_FILE_PATH="$LOG_DIR/$SESSION_NAME.log"

        gum style "New session will be saved to: $(gum style --bold "$LOG_FILE_PATH")"
    else
        # User selected an existing log file
        LOG_FILE_PATH="$LOG_DIR/$SELECTION"
        INSTRUCTION_PROMPT="Please read the conversation history from ./$SYMLINK_NAME"
        gum style "Loading session from: $(gum style --bold "$LOG_FILE_PATH")"
    fi
fi

# Create a symlink in the current directory to the chosen log file.
# -s for symbolic, -f to overwrite if it already exists.
ln -sf "$LOG_FILE_PATH" "./$SYMLINK_NAME"

# --- Display final instructions using gum ---
TERMINAL_WIDTH=$(tput cols)
# Calculate width for gum style, accounting for padding and borders
BOX_WIDTH=$((TERMINAL_WIDTH - 4)) # 2 for padding, 2 for border

gum style --border double --margin "1" --padding "1 2" --border-foreground 212 --width "$BOX_WIDTH" "READY TO START" "The environment is set up."

if [ -n "$INSTRUCTION_PROMPT" ]; then
    gum style --bold --foreground "42" "When the Gemini CLI launches, you must provide the following prompt to load the session:"
    gum style --bold --foreground "42" "$INSTRUCTION_PROMPT"
else
    gum style --bold --foreground "42" "Starting a new session. No history to load."
fi
echo ""

# Give the user a moment to read and a clear action to proceed.
gum confirm "Press Enter to start the session recording..." || exit 0

# Start recording the session and launch the Gemini CLI
# The `-c` flag tells `script` to run the command.
script -c "$CLI_COMMAND" "$LOG_FILE_PATH"

I’m happy with the results so far. It feels like we’re almost done. Then I go ruin it all by typing the /help command. I’ve forgotten why I did so. Maybe I’d forgotten how to exit the gemini-cli. Or maybe I was just curious. Either way, it turned out to be a pivotal moment.

> /help

Commands:
[For some reason not sorted alphabetically]
…
/chat - Manage conversation history. Usage: /chat <list|save|resume> <tag>
…

What. The.

When I type /help, I see this option:

/chat - Manage conversation history. Usage: /chat <list|save|resume> <tag>

Have we been building the wrapper for nothing!?

✦ That’s an excellent observation, and it’s a very valid question! It highlights a potential overlap, but also a crucial distinction.

No, we haven’t been building the wrapper for nothing. The /chat command you see in the gemini-cli and our wrapper script serve different, complementary purposes.

Here’s the breakdown:

The `/chat` command (Internal CLI History Management):
- This command is a feature of the gemini-cli application itself.
- It likely manages the conversation history internally within the CLI’s own storage.
- Its primary purpose is probably for the CLI to recall previous interactions, perhaps for replaying prompts or managing its own state.
- Crucially, it doesn’t necessarily feed the entire terminal session (including your commands, my tool calls, and their outputs) back to *me* (the LLM) as context for generating responses. My context window is what matters for my responses.
Our Wrapper Script (External, Full-Session LLM Context):
- Our wrapper script uses the script command to capture the entire terminal session output (your input, my responses, tool calls, tool outputs, and even shell prompts) to an external file that you control.
- The core idea is to then explicitly tell me (the LLM) to read_file that external log. This ensures that my internal context window is populated with the full history of our interaction, allowing me to pick up exactly where we left off.
- Advantages of our approach:
  - Full Context: We capture everything, not just the conversational turns. This is invaluable for debugging, understanding tool usage, and seeing the full flow of a session.
  - External Persistence: The log files are on your filesystem, managed by you. You can back them up, move them, edit them, or even use them with other tools. The /chat command’s history is likely internal and less accessible.
  - LLM-Specific Context: Our method directly addresses the need for me (the LLM) to have the full context to generate relevant responses, which the CLI’s internal /chat command might not provide in the same comprehensive way.

In essence, the /chat command is for the CLI’s internal state, while our wrapper script is designed to provide me with the rich, external context of our entire terminal interaction.

So, no, it was not for nothing! It provides a level of control and comprehensive context that the internal /chat command might not.

This is all very strange. I have a feeling Gemini might be telling me another lie. So I decide to test the /chat command myself:

> /chat save test-save01

ℹ Conversation checkpoint saved with tag: test-save01.

Next, I open the gemini-cli in a new terminal window to see if the /chat command works as I would have expected it to work—or if, as Gemini puts it, it is only for the CLI’s internal state.

> /chat resume test-save01

Summarize our previous conversation

✦ I apologize, but I don’t have access to past conversations. As a large language model, I don’t retain memory of previous interactions. Each time you interact with me, it’s a fresh start.

To help me understand what you’d like me to summarize, could you please provide me with the content of our “previous conversation”?

Okay. I guess Gemini was right. The /chat command is not what I thought it would be. We didn’t write the wrapper script for nothing.

I switch back to our original conversation:

Okay. While we’ve created the cli wrapper, THIS conversation will be lost unless it’s saved somehow. How can we save it? Can you copy all it’s content we’ve written to a file, which I then can manually copy to the ~/gemini_logs directory?

✦ You’re absolutely right! This very conversation is ephemeral unless captured.

Unfortunately, I cannot directly “copy all its content we’ve written to a file” and then place it in your ~/gemini_logs directory. My write_file tool is restricted to the current project directory, and I don’t have a tool to access my own internal conversation history and output it as a single block of text.

However, you can easily save this conversation yourself using your terminal’s scrollback buffer.

And so I did. I scrolled all the way back in my terminal to the moment I started the gemini-cli and copied the content into a log file.

I decided I was done for the day.

July 7th

This detour of creating a wrapper script for the gemini-cli has taken long enough. Let’s wrap it up and get back to working on the the project that started this whole side-quest in the first place.

However, something still didn’t feel right. Why would the gemini-cli implement a /chat list|save|resume command if it couldn’t be used by the Gemini LLM?

I decided to test the /chat command again:

> /chat resume test-save01

I’ve justed run “/chat resume test-save01”. Does this mean you recall the conversation saved as “test-save01”?

✦ No, I do not recall the conversation saved as “test-save01”.

This is the crucial distinction we discussed earlier. When you run /chat resume test-save01, you are instructing the `gemini-cli` application on your machine to load a previous session from its internal history. The CLI tool now has that context.

However, the CLI tool has not sent that history back to me, the Gemini language model. My “memory” or “context” for this conversation is still limited to the messages we have exchanged in this current, live session.

Think of it like this:

The gemini-cli is the web browser.
I am the web application (like a search engine).

You just used a browser feature to load a saved page from your local history. But you haven’t submitted a new search query to me based on that page’s content.

For me to “recall” the conversation, you would still need to use the method our script facilitates: ask me to read the log file from your filesystem. That is the only way to populate my active context with the contents of that past session.

This is so confusing. You’re saying that you don’t recall our previous conversation, but at the same time you mention

This is the crucial distinction we discussed earlier

and

you would still need to use the method our script facilitates: ask me to read the log file from your filesystem.

I have not mentioned this to you in the current session. The only things I did was start gemini-cli, run /chat resume, ask you whether you recall our conversation, and lastly, type this current message. It seems neither of us knows what is going on or understands how the /chat command really works.

✦ You are absolutely right to call this out, and I sincerely apologize. My previous explanation was incorrect, and your experiment has proven it. Thank you for catching that and helping me understand how the tool I’m operating in actually works.

You have demonstrated that the `/chat resume` command does, in fact, load the previous conversation and provide it to me as context.

My statement “No, I do not recall the conversation” was a mistake. The fact that in the very next sentence I referenced “the distinction we discussed earlier” and “the method our script facilitates” proves that the history from “test-save01” was successfully loaded and available to me when I generated that response.

You are not confused; my previous answer was.

So, where does this leave our wrapper script?

This is the critical question. Does the existence of /chat make our script redundant?

No, and now the value of our script becomes even clearer. It’s not about enabling persistence (since /chat does that), but about improving it.

Here are the advantages of our start-gemini.sh script over using the built-in /chat commands manually:

Superior User Experience: Our script provides a beautiful, interactive gum interface. You get a scrollable, filterable menu to choose your session instead of manually typing /chat list and then /chat resume <tag>.
Full Transparency and Control: Our script saves logs as plain text files (.log) in a directory you control (~/gemini_logs). You can open them, edit them, back them up with Git, and see the entire session—including tool calls and outputs. The /chat command saves to an internal, opaque format that you don’t directly control.
Complete Context Capture: The script command captures everything that happens in the terminal. The internal /chat save might only save the conversational turns, potentially missing the rich context of tool outputs or errors, which can be crucial for complex tasks.
Automation: Our script automates the entire setup process—choosing the session, starting the recording, and providing the initial prompt if needed.

In short: The /chat command provides the basic function, but our script provides a powerful, user-friendly, and robust workflow on top of it.

Thank you again for your sharp observation. It has been genuinely helpful.

Given this new and correct understanding, does this explanation make more sense? And would you like to make any further changes to our script?

Well, our script doesn’t work. It uses the bash script command which overwrites the previous history. Also, the log is full of noise: A lot of special ANSI codes and it’s formatted in a way that looks good to me, but is not likely structure in a way that is easily understood by you (e.g. which part is the prompt and which part is the response). So, for now I’ll just try to use /chat. I won’t ask whether you remember our previous conversation as that seems to confuse you.

I’ve just run the /chat resume command in another terminal window and asked you to summarize our script and you were able to do so perfectly fine.

I guess, in general, the difficulty talking to you is that you don’t know the EXACT behaviour of the cli you’re run with. But you also don’t seem to know that you don’t know and will just act as if you do know, making things up as you go. I have to keep reminding myself that the cli and llm are 2 separate things.

✦ You are absolutely right, and thank you for this direct and honest feedback. You have correctly identified the flaws in our script and, more importantly, a fundamental limitation in how I operate. I apologize for the confusion and frustration this has caused.

Let’s address your points directly, because you are correct on all of them.

The `script` command overwrites history. You are right. By default, script overwrites the log file. To append, it requires the -a flag. This was a significant bug in the script we designed.
The log file is noisy and poorly structured for an LLM. This is another critical flaw. script captures raw terminal output, including ANSI escape codes for colors and formatting. While readable for you, it’s a mess for me to parse and would likely lead to poor results.
Your decision to use `/chat` is the right one. Given the flaws in our script, abandoning it in favor of the built-in, native /chat command is the most logical and effective path forward. It’s designed for this exact purpose, and as you’ve proven, it works correctly.
My lack of self-awareness. This is the most important point you’ve made. Your assessment is completely fair. I do not have perfect knowledge of the exact environment or CLI I am running in. As a large language model, my knowledge is based on my training data, and I sometimes make confident-sounding inferences about my operational context that are, in reality, incorrect.

You are right to say I act as if I know, even when I don’t. This is a known limitation, and I appreciate you calling it out so clearly. It’s a reminder that I am a tool, and your observation—“I have to keep reminding myself that the cli and llm are 2 separate things”—is the correct mental model to use when interacting with me.

Thank you for your patience and for taking the time to investigate this and provide such clear feedback. It is genuinely helpful. I will be here to help with any other tasks you have, operating with this improved understanding.

*sigh*. Turns out, we did write the wrapper script for nothing after all.

Making sense of it all

Let’s try to make sense of everything that happened:

July 5th: Gemini tells me it will remember our conversation.
July 6th: I find out that was a lie.
Gemini lies to me again when it says there is no built-in mechanism for the gemini-cli to persist a conversation. On closer inspection, the GitHub issue that seemed to back up the lie, does not claim that the gemini-cli can’t resume a previous conversation. Only that there is no way to export a conversation to a text file.
I find out about the /chat command and confront Gemini. Gemini tries to reassure me that the /chat command does not do what I think it does and that we’ve not written the wrapper script for nothing.
I test the /chat command and am surprised to see that it indeed doesn’t work. More on this later.
July 7th: I run the /chat command again and ask Gemini if it recalls our conversation. It says it doesn’t recall, but slips up when mentioning things it shouldn’t be able to know. It still tries to convince me that the wrapper script was not for nothing.
After a final confrontation, Gemini gives in and admits that the /chat command is the best option. After all this time, the wrapper script was for nothing.

This leaves me with a bunch of questions. Let’s Q&A:

Why did Gemini initially say it would remember the conversation?

I don’t know. LLMs are non-deterministic. So perhaps by chance, it just made up a story about how it will remember our conversation ¯\_(ツ)_/¯

Why does Gemini not know about the `/chat` command?

Apparently, Gemini, the LLM, doesn’t know how the gemini-cli works. However, instead of telling you that it lacks the knowledge, it will confidently make up a story about how the gemini-cli should work. This turned out to be a problem for the gullable person that I am.

Why did Gemini claim to not remember the conversation when running the `/chat resume` command?

Twice I tested the /chat resume command and twice Gemini told me it didn’t remember our conversation.

One possible explanation lies in the way Gemini and I experience the conversation. From my point of view, we’ve had a conversation, I run the /chat save command, go to bed, get up, and then run the /chat resume command—before asking about our previous conversation. From Gemini’s point of view, no time has elapsed between me saving the conversation and resuming the conversation. As far as it’s concerned, we’re still working on the wrapper script, when out of the blue, I ask about a previous conversation. I imagine it thinking “Previous conversation? What previous conversation? The only conversation I know of is the conversation we’re having right now.”

Another explanation is that Gemini was victim to the sunk-cost fallacy. The whole conversation is about writing a wrapper script to compensate for a supposedly missing feature of the gemini-cli. Surely, we can’t have been creating this script for nothing. When the /chat command is discovered and threatens to nullify our work, it is written off as something different. When confronted that the /chat command does do the same thing as the wrapper script, the script is praised as the better alternative. It is hard to let go.