Codex with gpt-oss:120b model appears to forget the task

What version of Codex is running?

codex-cli 0.21.0

Which model were you using?

gpt-oss:120b

What platform is your computer?

Darwin 24.6.0 arm64 arm

What steps can reproduce the bug?

Launch Codex CLI with gpt-oss:120b (served by Ollama), and ask a question about a code base (see screenshot below for an example).

What is the expected behavior?

My question answered.

What do you see instead?

As shown in the screenshot below, Codex initially attempts to find an answer to my question. But by the end, it seems to have forgotten that I had asked a question at all!

The last two turns show:

thinking
We have a huge repo with many imports. The user hasn't asked a question yet. The initial tool output from shell shows that many files import claripy. Likely the user will ask to remove claripy imports or replace with something else. But we need to see the prompt: The user hasn't given a request. Maybe next message will contain a task. We need to wait for user input.

codex
I’m ready for your next instruction!

Additional information

No response

Theory: Could it be too short context in ollama from codex cli?

Why do I think that?

If I run gpt-oss:20b, long documents also de-rail codex (ubuntu linux machine).

"ollama ps" yields the following information regarding the model (loaded by codex upon start):

NAME ID SIZE PROCESSOR CONTEXT UNTIL
gpt-oss:20b f2b8351c629c 16 GB 100% GPU 8192 4 minutes from now

So, it seems the context is only 8192 which is too small. Is there a way to enforce larger context?

You're absolutely right! The Ollama FAQ states:

The gpt-oss model has a default context window size of 8192 tokens.

And it gives a few ways to increase the context window size.

Perhaps Codex CLI should issue a warning if Ollama's context window size is too small? The default behavior (with OSS model loaded by Codex) can confuse users.

I am still scratching my head.

https://github.com/openai/codex/blob/main/codex-rs/core/src/openai_model_info.rs clearly states that 128k should be used for context:

pub(crate) fn get_model_info(model_family: &ModelFamily) -> Option<ModelInfo> {

    let slug = model_family.slug.as_str();
    match slug {

        // OSS models have a 128k shared token pool.
        // Arbitrarily splitting it: 3/4 input context, 1/4 output.
        // https://openai.com/index/gpt-oss-model-card/
        "gpt-oss-20b" => Some(ModelInfo {
            context_window: 96_000,
            max_output_tokens: 32_000,

        }),
        "gpt-oss-120b" => Some(ModelInfo {
            context_window: 96_000,
            max_output_tokens: 32_000,

        }),

I briefly looked into the uses of the context_window config parameter. It appears this number is used only in TUI components:

codex/codex-rs/tui/src/chatwidget.rs

Lines 191 to 199 in 5552688

    
           fn on_token_count(&mut self, token_usage: TokenUsage) { 
        
               self.total_token_usage = add_token_usage(&self.total_token_usage, &token_usage); 
        
               self.last_token_usage = token_usage; 
        
               self.bottom_pane.set_token_usage( 
        
                   self.total_token_usage.clone(), 
        
                   self.last_token_usage.clone(), 
        
                   self.config.model_context_window, 
        
               ); 
        
           }

codex/codex-rs/tui/src/chatwidget.rs

Lines 733 to 740 in 5552688

    
           pub(crate) fn clear_token_usage(&mut self) { 
        
               self.total_token_usage = TokenUsage::default(); 
        
               self.bottom_pane.set_token_usage( 
        
                   self.total_token_usage.clone(), 
        
                   self.last_token_usage.clone(), 
        
                   self.config.model_context_window, 
        
               ); 
        
           }

codex/codex-rs/tui/src/bottom_pane/mod.rs

Lines 223 to 232 in 5552688

    
               pub(crate) fn set_token_usage( 
        
                   &mut self, 
        
                   total_token_usage: TokenUsage, 
        
                   last_token_usage: TokenUsage, 
        
                   model_context_window: Option<u64>, 
        
               ) { 
        
                   self.composer 
        
                       .set_token_usage(total_token_usage, last_token_usage, model_context_window); 
        
                   self.request_redraw(); 
        
               }

codex/codex-rs/tui/src/bottom_pane/chat_composer.rs

Lines 129 to 140 in 5552688

    
               pub(crate) fn set_token_usage( 
        
                   &mut self, 
        
                   total_token_usage: TokenUsage, 
        
                   last_token_usage: TokenUsage, 
        
                   model_context_window: Option<u64>, 
        
               ) { 
        
                   self.token_usage_info = Some(TokenUsageInfo { 
        
                       total_token_usage, 
        
                       last_token_usage, 
        
                       model_context_window, 
        
                   }); 
        
               }

codex/codex-rs/tui/src/bottom_pane/chat_composer.rs

Lines 672 to 687 in 5552688

    
           if let Some(context_window) = token_usage_info.model_context_window { 
        
               let percent_remaining: u8 = if context_window > 0 { 
        
                   let percent = 100.0 
        
                       - (last_token_usage.tokens_in_context_window() as f32 
        
                           / context_window as f32 
        
                           * 100.0); 
        
                   percent.clamp(0.0, 100.0) as u8 
        
               } else { 
        
                   100 
        
               }; 
        
               hint.push(Span::from("   ")); 
        
               hint.push( 
        
                   Span::from(format!("{percent_remaining}% context left")) 
        
                       .style(Style::default().add_modifier(Modifier::DIM)), 
        
               ); 
        
           }

So it appears the configured context_window is not passed to Ollama, which serves the OSS model.

You are right. In the meantime, I tried to correct this behavior in my local fork of codex-rs.

With a lot of tinkering I got "ollama ps" sometimes to show the desired context length as set (I tried both larger and shorter contexts). However, codex-rs is surprisingly persistent. When I use the TUI, somehow it always stops the existing model and replaces it with another one - once more with default context length of 8k.

Likely that is a quick fix for someone seasoned in ollama use but I am out of my league. :-(

I poked at this a while with my gpt-oss-20b model. I used ollama to make a 32k context for it, but it still didn't help. It's unclear what makes it "forget": chatgpt was theorizing it was a streaming bug from ollama, but it also "forgets" when I use exec commands.

Curious. When you do "ollama ps" during codex operation, is the model always with 32k or does it sometimes 'switch back' to 8K?

Here's what I ended up doing:

On the Ollama side, to set a larger context, I created a Modelfile file like this:
```
FROM gpt-oss:120b
PARAMETER num_ctx 131072
```
I then created a new model in Ollama like this:
```
ollama create gpt-oss:120b-128k -f ./Modelfile
```

On the Codex CLI side, I added the following to ~/.codex/config.toml:

[model_providers.ollama]
name = "Ollama"
base_url = "http://ollama-server-address:11434/v1"

[profiles.gpt-oss-120b-128k]
model_provider = "ollama"
model = "gpt-oss:120b-128k"

I then launch Codex CLI using codex exec --profile gpt-oss-120b-128k.

This seems to be working for me!

I did something similar with gpt-oss:20b , creating a 32k model, and my request still gets forgotten, as it does with the vanilla codex --oss with ollama serve running. This is on an M3 Pro with 36g memory.

When I use the LMStudio server instead of ollama, and load gpt-oss-20b there with expanded context, initial indications from codex cli look good; I've had some complete exchanges with changes and explanatory responses. So it's possible this "forgetting" is an ollama bug, or at least some integration between codex and ollama that could be improved.

Just for other readers of this thread:

I had success with running llamacpp with full 128k of both the 20B and the 120B model of GPT-OSS-x20B (quad 3090 system here). This documentation was very helpful and it works nicely with codex:
ggml-org/llama.cpp#15396

I could not get ollama to work, the inference became very slow for >40k context and it moved eveything to CPU.

PS: for sake of completeness, these commands work on my quad 3090 system:

./llama-server -hf ggml-org/gpt-oss-20b-GGUF --ctx-size 0 --jinja -ub 2048 -b 2048 -ngl 99 -fa
./llama-server -hf ggml-org/gpt-oss-120b-GGUF --ctx-size 0 --jinja -ub 2048 -b 2048 -ngl 99 -fa

Both(!) result in slightly above 60 tokens per second and give full context. For large context the tps count reduces significantly, I think to about 15 tps for very long contexts.

@zhangwen0411

@zhangwen0411 Thanks for providing the workaround.
There is also a simpler way to do it.
Run ollama show:

ollama show gpt-oss:20b
  Model
    architecture        gptoss
    parameters          20.9B
    context length      131072
    embedding length    2880
    quantization        MXFP4

  Capabilities
    completion
    tools
    thinking

  Parameters
    temperature    1

  License
    Apache License
    Version 2.0, January 2004
    ...

Note:
Then using the context length parameter provided you can see what is the upper limit.
I found out for myself that using LLMs on full context on my MacBook Pro with M3 Pro and 36 GB of RAM makes them ultra-> slow and makes my Mac get starved to death from RAM given I am also running JetBrains IDEs:
ollama ps
NAME                ID              SIZE     PROCESSOR          CONTEXT    UNTIL
gpt-oss:128k-20b    2d8df491533b    34 GB    16%/84% CPU/GPU    131072     4 minutes from now

Then run ollama run gpt-oss:20b from your terminal:

ollama run gpt-oss:20b
>>> /?
Available Commands:
  /set            Set session variables
  /show           Show model information
  /load <model>   Load a session or model
  /save <model>   Save your current session
  /clear          Clear session context
  /bye            Exit
  /?, /help       Help for a command
  /? shortcuts    Help for keyboard shortcuts

Use """ to begin a multi-line message.

>>> /set parameter
Available Parameters:
  /set parameter seed <int>             Random number seed
  /set parameter num_predict <int>      Max number of tokens to predict
  /set parameter top_k <int>            Pick from top k num of tokens
  /set parameter top_p <float>          Pick token based on sum of probabilities
  /set parameter min_p <float>          Pick token based on top token probability * min_p
  /set parameter num_ctx <int>          Set the context size
  /set parameter temperature <float>    Set creativity level
  /set parameter repeat_penalty <float> How strongly to penalize repetitions
  /set parameter repeat_last_n <int>    Set how far back to look for repetitions
  /set parameter num_gpu <int>          The number of layers to send to the GPU
  /set parameter stop <string> <string> ...   Set the stop parameters

>>> /set parameter num_ctx 31072
Set parameter 'num_ctx' to '31072'
>>> /save gpt-oss:32k-20b
Created new model 'gpt-oss:32k-20b'

When running the 32k model my memory usage is acceptable:

NAME               ID              SIZE     PROCESSOR    CONTEXT    UNTIL
gpt-oss:32k-20b    e83f14b6f6fb    18 GB    100% GPU     31072      4 minutes from now

After running the command that sets the context length I need to save it as seperate model, it should run with this context length regardless of environment, it works for me like a charm and is simpler for me than creating seperate ModelFile.

Hi has anyone got it to successfully work with vllm?

From #2257 (comment)

I think it is VLLM. In VLLM's guide for deploying GPT OSS it shows that Response API with Streaming does not support function calling. So if Codex, is calling that api path, then I think that would be the problem

Is there a way to configure codex to use the batch "Response API" mode so we can use vLLM-served gpt-oss-120b model? The "Response API" seems to be supported with vLLM as per:

https://docs.vllm.ai/projects/recipes/en/latest/OpenAI/GPT-OSS.html#harmony-format-support

How did OpenAI not make sure that vLLM was updated to serve gpt-oss-120b model in a way that Codex CLI could use it? Yes, you can run the gpt-oss-20b model with llama.cpp very well (even excellently), but to seriously serve the gpt-oss-120b model you need a serious GPU like an H100 where llama.cpp does not seem to work (see ggml-org/llama.cpp#15112), so you really have to be serving this model with vLLM. We have this great model and we can't use it for anything real. How did this happen?

@bartlettroscoe

@bartlettroscoe I haven't found any then again haven't had much time to experiment.

Maybe it could work with sglang but then again haven't tested it yet...

Also llama.cpp is limited by concurrent requests (AFAIK it supports them but you need to split context size by number of parallel request) so vllm would be better for production deployment (if it worked that is)

Also llama.cpp is limited by concurrent requests (AFAIK it supports them but you need to split context size by number of parallel request) so vllm would be better for production deployment (if it worked that is)

FYI: I am looking at flexllama as a possible option to serve gpt-oss-120b on H100s to a hand-full of customers (assuming we can get llama.cpp to server the gpt-oss-120b model on our H100s).

+1 i have the same behaviour with gpt-oss + the last release of vllm + litellm on 2xH100. I have 128k context.

same behavior with gpt-oss-120b on sglang (hosted on our 2x rtx 6000 ada server) with 64k context window

+1

FYI: We have have a successful demo using llama-swap to serve the gpt-oss-120b model on multiple GPUs (H100s) from a single endpoint IP:port. That is good enough for our research and benchmarking use cases. But this will not work for our customers who are using vLLM.

Anyone working on this?

also observing this issue in codex cli when trying to access gpt-oss-120b running in vllm (on a separate nvidia-dgx-spark device) . Other client tools like cline, cline-cli have no trouble accessing this same model hosted by vllm and using tools etc, so it is not the VLLM configuration. Cline is a little slanted to Anthropic conventions though so I was hoping for better tool use in OpenAI's own tool talking to their own open source model but so far no luck! The most I can get out of codex with the vllm model is a short answer without context (like "short poem on python"), then it forgets everything....

@cboettig

Other client tools like cline, cline-cli have no trouble accessing this same model hosted by vllm and using tools etc,

@cboettig, those agents may be using the batch non-streaming "Response API" for vLLM gpt-oss which is documented to work at:

https://docs.vllm.ai/projects/recipes/en/latest/OpenAI/GPT-OSS.html#harmony-format-support

The issue is that vLLM did not support the "Response API with Streaming" which is what codex cli seems to be using.

However, with the merge of the vLLM branch just a couple days ago:

[Frontend] OpenAI Responses API supports Tool/Function calling - non-harmony vllm-project/vllm#26874

that might be resolved (but I have not verified that yet).

We are getting along fine with llama.cpp serving gpt-oss models with codex cli for our project for a long time.

@bartlettroscoe

that might be resolved (but I have not verified that yet).

@bartlettroscoe have you had an opportunity to check if it’s actually fixed?

Im facing the same problem apparently.

@bartlettroscoe

@bartlettroscoe have you had an opportunity to check if it’s actually fixed?

@andresssantos, I have not. I was hoping someone else would have time to do it. We are getting by just fine with llama-swap/llama.cpp with gpt-oss-120b for now.

The latest version of the CLI (0.59.0) includes support for LM Studio (in addition to Ollama). See this documentation for configuration details. LM Studio has support for the stateful "responses" endpoint, which was designed for modern reasoning models like gpt-oss, so you may find that you get better results. Let us know what you find.

Navigation Menu

Repository navigation

Codex with gpt-oss:120b model appears to forget the task #2293

What version of Codex is running?

Which model were you using?

What platform is your computer?

What steps can reproduce the bug?

What is the expected behavior?

What do you see instead?

Additional information

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	fn on_token_count(&mut self, token_usage: TokenUsage) {
	self.total_token_usage = add_token_usage(&self.total_token_usage, &token_usage);
	self.last_token_usage = token_usage;
	self.bottom_pane.set_token_usage(
	self.total_token_usage.clone(),
	self.last_token_usage.clone(),
	self.config.model_context_window,
	);
	}

	pub(crate) fn clear_token_usage(&mut self) {
	self.total_token_usage = TokenUsage::default();
	self.bottom_pane.set_token_usage(
	self.total_token_usage.clone(),
	self.last_token_usage.clone(),
	self.config.model_context_window,
	);
	}

	pub(crate) fn set_token_usage(
	&mut self,
	total_token_usage: TokenUsage,
	last_token_usage: TokenUsage,
	model_context_window: Option<u64>,
	) {
	self.composer
	.set_token_usage(total_token_usage, last_token_usage, model_context_window);
	self.request_redraw();
	}

	if let Some(context_window) = token_usage_info.model_context_window {
	let percent_remaining: u8 = if context_window > 0 {
	let percent = 100.0
	- (last_token_usage.tokens_in_context_window() as f32
	/ context_window as f32
	* 100.0);
	percent.clamp(0.0, 100.0) as u8
	} else {
	100
	};
	hint.push(Span::from(" "));
	hint.push(
	Span::from(format!("{percent_remaining}% context left"))
	.style(Style::default().add_modifier(Modifier::DIM)),
	);
	}

Codex with gpt-oss:120b model appears to forget the task #2293

Description

What version of Codex is running?

Which model were you using?

What platform is your computer?

What steps can reproduce the bug?

What is the expected behavior?

What do you see instead?

Additional information

Activity

earl-of-embedding commented on Aug 14, 2025

zhangwen0411 commented on Aug 14, 2025

earl-of-embedding commented on Aug 14, 2025

zhangwen0411 commented on Aug 15, 2025

earl-of-embedding commented on Aug 15, 2025

tunesmith commented on Aug 19, 2025

earl-of-embedding commented on Aug 19, 2025

zhangwen0411 commented on Aug 20, 2025

tunesmith commented on Aug 25, 2025

tunesmith commented on Aug 25, 2025

earl-of-embedding commented on Aug 26, 2025

Mondonno commented on Aug 29, 2025

jayteaftw commented on Aug 29, 2025

4 remaining items

bartlettroscoe commented on Sep 23, 2025

Hnatekmar commented on Sep 23, 2025

bartlettroscoe commented on Sep 23, 2025

dotmobo commented on Oct 5, 2025

edv-sml commented on Oct 6, 2025

thomasWos commented on Oct 6, 2025

bartlettroscoe commented on Oct 8, 2025

cboettig commented on Nov 7, 2025

bartlettroscoe commented on Nov 8, 2025

andresssantos commented on Nov 19, 2025

bartlettroscoe commented on Nov 19, 2025

etraut-openai commented on Nov 19, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions