Very very slowness

Thanks for the bug report, but there's not enough here for us to evaluate. You mentioned that you uploaded a thread. Could you provide the thread ID here so we can look it up? Did you provide additional details in the /feedback?

Thanks for the bug report, but there's not enough here for us to evaluate. You mentioned that you uploaded a thread. Could you provide the thread ID here so we can look it up? Did you provide additional details in the /feedback?

thread ID 019b0bf8-3bc8-7361-8c64-e7747e1f0593。

An easy question，the codex spends about 10 minutes. Very very slowness, it ran smoothly when I used it on 12.09. But I encountered lag when using it on 12.10.

I looked at the session you uploaded, and I'm not seeing anything unusual. The entire session lasted a little over two minutes, and responses from the model looked reasonable. Most of them were under a second. Are you sure this is the session that was slow? I see that this session was using 0.69.0, which was released after your initial bug report.

How are you invoking codex? Are you running the CLI and interacting with the terminal UI (TUI)? I suspect that you're invoking it programmatically from an agent wrapper because I see "/raid/data/yc/try_agentGym/rl_qwen3/swift_rl" in your session data. Perhaps the problem you're seeing is in the agent wrapper script.

I looked at the session you uploaded, and I'm not seeing anything unusual. The entire session lasted a little over two minutes, and responses from the model looked reasonable. Most of them were under a second. Are you sure this is the session that was slow? I see that this session was using 0.69.0, which was released after your initial bug report. How are you invoking codex? Are you running the CLI and interacting with the terminal UI (TUI)? I suspect that you're invoking it programmatically from an agent wrapper because I see "/raid/data/yc/try_agentGym/rl_qwen3/swift_rl" in your session data. Perhaps the problem you're seeing is in the agent wrapper script.

Codex automatically updated to version 0.69 today. The thread ID I provided is from the chat log I just recorded, because my chat was also extremely slow. I was using Codex in the terminal, and my machine most likely doesn't have a proxy (at least I've never set one up). You mentioned the entire chat process only took 2 minutes, but I saw it take 20 minutes in my terminal. I'll send you a screenshot; take a look.

<img width="1998" height="460" alt="Image" src="https://github.com/user-attachments/assets/53286f73-7497-45aa-a7d6-4ea94f95a370" />

The thread ID in the screenshot is also this: 019b0bf8-3bc8-7361-8c64-e7747e1f0593

I discovered a common thread in my responses: they all experienced a freeze of approximately 20 minutes before the terminal finally responded.

<img width="2016" height="582" alt="Image" src="https://github.com/user-attachments/assets/f91d1b23-a7a2-48f0-a3b9-50e41fd796c4" />

<img width="1876" height="192" alt="Image" src="https://github.com/user-attachments/assets/35db00e9-a236-4d5b-b36c-33f954f61c2f" />

That is an interesting clue. I looked in our code, and I don't see any 20-minute timeout values.

It looks like the long time may be attributable to the local tool call rather than a call to the model. Is there a common pattern for the commands that take a long time? For example, do they all involve grep?

That is an interesting clue. I looked in our code, and I don't see any 20-minute timeout values. It looks like the long time may be attributable to the local tool call rather than a call to the model. Is there a common pattern for the commands that take a long time? For example, do they all involve ?grep

Thank you for your suggestion. I carefully reviewed the log records under ~/.codex/sessions/2025/12/11 and found a common feature in these long intervals: "After waiting for a long time, the first record output is always ghost_snapshot". I guess it's because there are a lot of model training weights under my output/ directory, and ghost_snapshot takes a long time to record these large files?

<img width="2226" height="270" alt="Image" src="https://github.com/user-attachments/assets/8ea66ccd-e7b7-4ccf-a32d-c55f73817f1a" />

<img width="2170" height="352" alt="Image" src="https://github.com/user-attachments/assets/b681edbe-9f64-4530-aaea-758ad19f4cab" />

Hi, what is the size of your repo?
I will take a look at the logs

I see you have a lot of very large untracked files. As a quick solution you can either:

• add them to a proper .gitignore
• disable the ghost commit with --disable undo

Thank you so much! After I added

[features]
undo = false

, it ran smoothly. My problem is solved. I hope future developers will inform other users that undo can cause performance lag when scanning large local folders. I hope this feature can be optimized in future versions.

This PR adds a warning message.