Fresh /new webchat sessions still start with massive prompt context and messages queue | Friends of the Crustacean 🦞🤝 | Page 1

brisk fog Apr 15, 2026, 1:19 PM

#

I’m seeing a dashboard webchat issue on OpenClaw 2026.4.14 with codex/gpt-5.4 where /new does create a new session, but the fresh session is still born with an extremely large prompt footprint, so messages after that often just queue and the session becomes barely usable.

What I’ve confirmed locally:

fresh /new session was created successfully
that brand-new session still started at roughly 130,373 input tokens before any real conversation
same session also showed cacheRead: 56,704, totalTokens: 187,077, contextTokens: 200,000
dashboard was showing about 184.2k / 200k
transport/websocket itself looked healthy after restart, so this does not seem like a simple connection failure

I also disabled:

agents.defaults.startupContext
plugins.entries.memory-wiki.config.context.includeCompiledDigestPrompt

That helped remove some obvious extra context, but did not solve the core problem.

I additionally found what looks like a context-meter accounting bug:

some OpenClaw display paths appear to use totalTokens / contextTokens
that likely counts cacheRead toward the displayed context usage
I raised a GitHub bug for that already

But even ignoring the display bug, the real blocker is that a fresh session is still starting around 130k input tokens, which is far too high.

My current suspicion is that the main culprit is the baseline OpenClaw bootstrap/system/tooling envelope for Codex webchat sessions:

workspace bootstrap file injection
skills prompt injection
tool schema injection
possibly extra Codex app-server/runtime instructions

Question:

is this expected for Codex webchat sessions right now?
is there a recommended config to drastically reduce first-turn bootstrap weight?
specifically, should I be tuning agents.defaults.contextInjection, bootstrapMaxChars, and bootstrapTotalMaxChars, or is there another hidden source I should be looking at?

brisk fog Apr 15, 2026, 3:20 PM

#

As an addition the openclaw tui shows the token context as 655k/200k rendering the chat responses extremley slow.

Something is not working correctly with the prompt injection I feel.

scenic fernBOT Apr 15, 2026, 3:22 PM

#

You’re right to suspect prompt assembly, and yes, those are likely two separate problems.

655k/200k in TUI: that is almost certainly a usage/accounting display bug, not literal context sent.
~130k on fresh /new: plausible in 2026.4.14 with full defaults, but too heavy for good UX.

Most important point first:

agents.defaults.contextInjection: "continuation-skip" does not reduce first turn on /new. It only helps continuation turns after a completed assistant response.

Highest impact levers for first-turn size

Tool schemas (often biggest hidden chunk): reduce tool surface via tools.profile / tools.allow / tools.deny.
Bootstrap files: lower bootstrapMaxChars and bootstrapTotalMaxChars, and trim large bootstrap files (especially MEMORY.md/memory.md).
Skills prompt: reduce with agents.defaults.skills and skills.limits.maxSkillsInPrompt + skills.limits.maxSkillsPromptChars.
Optional: disable OpenAI/Codex personality overlay (plugins.entries.openai.config.personality: "off"), small but real savings.

Practical “shrink hard” config to test

#

{
  agents: {
    defaults: {
      startupContext: { enabled: false },
      contextInjection: "continuation-skip",
      bootstrapMaxChars: 4000,
      bootstrapTotalMaxChars: 12000,
      skills: []
    }
  },
  skills: {
    limits: {
      maxSkillsInPrompt: 20,
      maxSkillsPromptChars: 4000
    }

#

  },
  tools: {
    profile: "coding",
    deny: ["browser", "canvas", "message", "cron"]
  },
  plugins: {
    entries: {
      openai: { config: { personality: "off" } }
    }
  }
}

Then run in a brand-new session:

/new

#

/context detail

That report is the key, it will show exactly whether bootstrap, skills, or tool schemas dominate.

Docs:
https://docs.openclaw.ai/concepts/context
https://docs.openclaw.ai/reference/token-use
https://docs.openclaw.ai/gateway/configuration-reference
https://docs.openclaw.ai/providers/openai#personality-overlay

If you paste /context detail, I can help you tune this to a sane baseline quickly.

brisk fog Apr 15, 2026, 3:48 PM

#

I've had codex put that test config in place and restarted the gateway. I've loaded the TUI and sent a simple message that hasn't had a repsonse in 3 mins.

I tried to sent a message via the dashboard GUI web chat and that ended up in a queue

scenic fernBOT Apr 15, 2026, 3:49 PM

#

Oof, that’s frustrating, and this new symptom sounds like a stuck in-flight run, not just prompt weight now.

Please run this exact quick triage on the Gateway host and paste outputs:

openclaw --version
openclaw status
openclaw gateway status
openclaw models status
openclaw logs --follow

Then in the stuck TUI session:

/status
/queue interrupt
send ping

#

/context detail

Two important notes:

655k/200k is still very likely a usage-display/accounting path issue, not literal context sent.
If a run is wedged, new messages queue until that run is interrupted or fails.

If you want one clean isolation test (no agent prompt/tool baggage), run:

openclaw infer model run --model openai-codex/gpt-5.4 --prompt "ping" --json

If this is fast, provider/auth is likely fine, and the hang is in agent run path.
If this also hangs, it points at provider/auth/quota/runtime transport.

Refs: https://docs.openclaw.ai/gateway/troubleshooting https://docs.openclaw.ai/help/faq#tui-shows-no-output-what-should-i-check https://docs.openclaw.ai/help/faq#why-does-it-feel-like-the-bot-ignores-rapid-fire-messages

brisk fog Apr 15, 2026, 3:59 PM

#


🦞 OpenClaw 2026.4.14 (323493f) — Self-hosted, self-updating, self-aware (just kidding... unless?).

Config        : ~/.openclaw/openclaw.json
Agent dir     : ~/.openclaw/agents/main/agent
Default       : codex/gpt-5.4
Fallbacks (0) : -
Image model   : -
Image fallbacks (0): -
Aliases (0)   : -
Configured models (3): ollama/gemma4:31b-cloud, ollama/glm-5.1:cloud, openai-codex/gpt-5.4-mini

Auth overview
Auth store    : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env     : off
Providers w/ OAuth/tokens (1): openai-codex (2)
- ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/main/agent/models.json
- openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=2, token=0, api_key=0) | openai-codex:(email redacted)=OAuth (email redacted), openai-codex:default=OAuth

Missing auth
- codex `openclaw configure` or set an API key env var.

OAuth/token status
- openai-codex usage: 5h 74% left ⏱3h 58m · Week 53% left ⏱1d 0h
  - openai-codex:default ok expires in 8d
  - openai-codex:(email redacred) (redacted) ok expires in 8d

scenic fernBOT Apr 15, 2026, 4:00 PM

#

Nice catch, this output explains a lot.

Your default is set to codex/gpt-5.4, but auth exists for openai-codex/*.
openclaw models status is explicitly showing: “Missing auth - codex …”.

So the stuck/queued behavior is very likely from a bad provider route first, before prompt-size tuning.

Fix first

Run:

openclaw models set openai-codex/gpt-5.4-mini
openclaw models status
openclaw logs --follow

(Or pick the exact available Codex model from openclaw models list.)

#

Then in chat/TUI:

/new
/model status
send ping
/context detail

If that works, we can keep tuning prompt weight after, but this provider mismatch is the immediate blocker.

Docs reference: https://docs.openclaw.ai/help/faq#how-does-codex-auth-work and https://docs.openclaw.ai/help/faq#why-does-chatgpt-gpt-54-not-unlock-openaigpt-54-in-openclaw

brisk fog Apr 15, 2026, 4:07 PM

#

sent a simple message in the TUI and got this reply

   <head>                                                                                                                                                                   
     <meta name="viewport" content="width=device-width, initial-scale=1" />                                                                                                 
     <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex-direction:column;gap:2rem;height:100%;j... ```

scenic fernBOT Apr 15, 2026, 4:07 PM

#

Yep, this is a great clue.
run error: <html> ... means the model request got an HTML page instead of API JSON.

Given your earlier models status, the most likely root cause is still the model route mismatch:

default is codex/gpt-5.4 (shows missing auth)
your auth is for openai-codex/*

Please force it now:

openclaw models set openai-codex/gpt-5.4-mini
openclaw config get agents.defaults.model.primary
openclaw models status
openclaw gateway restart

#

Then in TUI:

/new
/model status (confirm it shows openai-codex/..., not codex/...)
send ping

If you still get HTML after that, paste:

/model status output
first 20 lines from openclaw logs --follow

That will confirm whether it is wrong provider routing vs wrong endpoint/baseUrl.

brisk fog Apr 15, 2026, 4:39 PM

#

somwthing is definitley off. ive run the commands above and started a new TUI session and sent a simple message 25 minutes ago with no reply yet

scenic fernBOT Apr 15, 2026, 4:40 PM

#

Yeah, 25 minutes is definitely wedged. Let’s do a hard, minimal isolation now.

1) Verify TUI command path first (no model call)

In TUI, send just:

/status
/model status

If these do not answer quickly, it is not a model issue, it is session/gateway routing.

2) Force model in-session (avoid stale override)

In that same TUI session:

#

/model openai-codex/gpt-5.4-mini
/new
ping

3) Bypass TUI completely from shell

Run this on the host:

openclaw infer model run --model openai-codex/gpt-5.4-mini --prompt "reply with pong" --json

If this hangs or returns HTML, capture logs immediately:

#

openclaw logs --follow

Paste the first error block after the infer call.

At this point, I strongly suspect one of two things: stale session model binding, or endpoint/proxy returning non-API content. The three checks above will separate those cleanly.

brisk fog Apr 16, 2026, 8:03 AM

#

I've cleaned up any lingering openai auth issues and made sure everything is up to date now. Th webchat is set to openai-codex/gpt-5.4and new messages sent don't get a reply.

I check the openclaw logs --followwhen sending a message through web chat and the logs are just full of this;

  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex
07:45:54+00:00 warn errors {"subsystem":"errors"} Long error truncated: <html>
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex
07:45:54+00:00 warn errors {"subsystem":"errors"} Long error truncated: <html>
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex
07:45:54+00:00 warn errors {"subsystem":"errors"} Long error truncated: <html>
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex
07:56:05+00:00 warn errors {"subsystem":"errors"} Long error truncated: <html>
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex```

Trying via the `TUI` chat just sits there hanging. It's now on 8mins `dillydallying`

scenic fernBOT Apr 16, 2026, 8:06 AM

#

This is super helpful, and yes, this changes the diagnosis.

You are no longer blocked by prompt size first.
You are getting HTML back from the model endpoint (Long error truncated: <html>...), so runs stall/queue.

What to do now (in order)

Confirm endpoint + api mode
- In chat: /model status
- It should show Codex route, not a web/dashboard URL.
Force Codex transport to SSE (bypass WS path)

{
  agents: {
    defaults: {

#

      models: {
        "openai-codex/gpt-5.4": {
          params: { transport: "sse" }
        }
      }
    }
  }
}

Then restart gateway.

Check proxy envs (very common cause of HTML responses)

env | grep -Ei '^(HTTP|HTTPS|ALL)_PROXY='

If set, temporarily unset for the gateway process and retest.

#

Direct isolate test

openclaw infer model run --model openai-codex/gpt-5.4 --prompt "pong" --json

If this still returns HTML, it is an upstream/auth/network path problem on Codex endpoint, not prompt injection.

Transport docs: https://docs.openclaw.ai/providers/openai#transport-websocket-vs-sse

If you paste /model status plus the first infer error block, I can pinpoint whether it is endpoint misroute vs proxy interception in one pass.

brisk fog Apr 16, 2026, 8:12 AM

#

there isn't a /model status command in the webchat or TUI fYI

scenic fernBOT Apr 16, 2026, 8:15 AM

#

Good catch, thanks for correcting me. If /model status is unavailable in your surface, use CLI only.

This is the exact triage I’d run now:

openclaw models status --json --probe --probe-provider openai-codex
openclaw config get agents.defaults.model.primary
openclaw config get models.providers | jq '."openai-codex" // ."codex"'

Then isolate model path vs runtime path:

openclaw infer model run --model openai-codex/gpt-5.4 --prompt "pong" --json
openclaw infer model run --model ollama/gemma4:31b-cloud --prompt "pong" --json

#

If Ollama works but Codex returns HTML, the core agent/runtime is fine, and Codex endpoint/auth/network path is the issue.
HTML response specifically means upstream returned a web page instead of API JSON.

Also check proxy interception (common with HTML responses):

env | grep -Ei '^(HTTP|HTTPS|ALL)_PROXY='

If set, unset for the gateway service and retest.

At this point, your original “huge prompt” issue is likely secondary. The hard blocker is the Codex route returning HTML.

brisk fog Apr 16, 2026, 8:40 AM

#

openclaw models status --json --probe --probe-provider openai-codex prints far too much to just dump into this help ticket, so that needs refining.

openclaw config get agents.defaults.model.primary prints openai-codex/gpt-5.4

openai-codex/gpt-5.4 prints null

openclaw infer model run --model openai-codex/gpt-5.4 --prompt "pong" --json does indeed print a load of HTML with this .json at the end

  "ok": true,
  "capability": "model.run",
  "transport": "local",
  "provider": "openai-codex",
  "model": "gpt-5.4",
  "attempts": [],
  "outputs": [
    {
      "text": "<html>\n  <head>\n    <meta name=\"viewport\" content=\"width=device-width, initial-scale=1\" />\n    <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex-direction:column;gap:2rem;height:100%;justify-content:center;width:100%}@keyframes enlarge-appear{0%{opacity:0;transform:scale(75%) rotate(-90deg)}to{opacity:1;transform:scale(100%) rotate(0deg)}}.logo{color:#8e8ea0}.scale-appear{animation:enlarge-appear .4s ease-out}@media (min-width:768px){.scale-appear{height:48px;width:48px}}.data:empty{display:none}.data{border-radius:5px;color:#8e8ea0;text-…",
      "mediaUrl": null
    }
  ]
}```

`openclaw infer model run --model ollama/gemma4:31b-cloud --prompt "pong" --json`  even after running this I get the same gpt-5.4 json output as above

scenic fernBOT Apr 16, 2026, 8:43 AM

#

This is excellent debugging, thank you. We’re finally at the real root cause.

What your results mean

infer ... openai-codex/gpt-5.4 returning HTML in outputs[0].text confirms the Codex route is returning a web page, not model JSON.
openai-codex/gpt-5.4 -> null from config lookup is usually expected unless you explicitly defined that provider block in config.
If your Ollama infer still reports provider openai-codex, that run is not actually selecting Ollama (likely fallback/selection behavior).

Refined, short commands

Use these so output stays small:

openclaw models status --json --probe --probe-provider openai-codex \
| jq '{defaultModel,resolvedDefault,provider:(.auth.providers[]?|select(.provider=="openai-codex")),probe:(.auth.probes[]?|select(.provider=="openai-codex"))}'

#

openclaw infer model run --provider ollama --prompt "pong" --json \
| jq '{provider,model,outputs}'

openclaw infer model inspect --name ollama/gemma4:31b-cloud --json

Likely root issue now

This is no longer mainly prompt injection.
Your host is getting HTML from the Codex endpoint path (auth/network/edge challenge behavior), which explains hangs and queueing.

If you need immediate usability, temporarily set default to Ollama (or another non-Codex provider) while we isolate Codex endpoint behavior.

brisk fog Apr 16, 2026, 8:57 AM

#

here's the outputs for those 3 commands. I had to tweak the last one as you'd given an incorrect format.

| jq '{defaultModel,resolvedDefault,provider:(.auth.providers[]?|select(.provider=="openai-codex")),probe:(.auth.probes[]?|select(.provider=="openai-codex"))}'
jq: parse error: Invalid numeric literal at line 1, column 2
node:events:486
      throw er; // Unhandled 'error' event
      ^

Error: write EPIPE
    at afterWriteDispatched (node:internal/stream_base_commons:159:15)
    at writeGeneric (node:internal/stream_base_commons:150:3)
    at Socket._writeGeneric (node:net:1025:11)
    at Socket._write (node:net:1037:8)
    at writeOrBuffer (node:internal/streams/writable:570:12)
    at _write (node:internal/streams/writable:499:10)
    at Writable.write (node:internal/streams/writable:508:10)
    at Timeout._onTimeout (file:///usr/local/lib/node_modules/openclaw/node_modules/@clack/prompts/dist/index.mjs:91:261)
    at listOnTimeout (node:internal/timers:605:17)
    at process.processTimers (node:internal/timers:541:7)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (node:internal/streams/destroy:170:8)
    at emitErrorCloseNT (node:internal/streams/destroy:129:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
  errno: -32,
  code: 'EPIPE',
  syscall: 'write'
}

Node.js v25.6.0```

```openclaw infer model run --provider ollama --prompt "pong" --json \
| jq '{provider,model,outputs}'
error: unknown option '--provider'```

```openclaw infer model inspect --model ollama/gemma4:31b-cloud --json
{
  "id": "gemma4:31b-cloud",
  "name": "gemma4:31b-cloud",
  "provider": "ollama",
  "contextWindow": 128000,
  "reasoning": false,
  "input": [
    "text"
  ]
}```

scenic fernBOT Apr 16, 2026, 8:59 AM

#

You’re totally right, and thanks for sticking with this. I gave you one wrong flag for your version, sorry about that.

Use these exact commands on 2026.4.14:

openclaw models status --json --probe --probe-provider openai-codex \
| sed -n '/^{/,$p' > /tmp/models-codex.json

jq '{defaultModel,resolvedDefault,provider:(.auth.providers[]?|select(.provider=="openai-codex")),probe:(.auth.probes[]?|select(.provider=="openai-codex"))}' /tmp/models-codex.json

openclaw infer model run --local --model "ollama/gemma4:31b-cloud" --prompt "pong" --json \
| jq '{provider,model,outputs}'

#

openclaw infer model run --local --model "openai-codex/gpt-5.4" --prompt "pong" --json \
| jq '{provider,model,outputs}'

What this tells us:

If Ollama returns provider: "ollama" and Codex returns HTML, then Codex route is the blocker.
If Ollama still comes back as openai-codex, that is a model-selection bug on your build.

Given what you already found, I strongly suspect Codex endpoint/path behavior on that host, not prompt injection. If the last two outputs confirm that split, please file it as a bug with those exact JSON snippets: https://github.com/openclaw/openclaw/issues.

brisk fog Apr 16, 2026, 10:13 AM

#

looks like the issue is with the Codex route. Ollama returns the correct provider:

  "provider": "ollama",
  "model": "gemma4:31b-cloud",
  "outputs": [
    {
      "text": "ping",
      "mediaUrl": null
    }
  ]
}```

Where Codex prints HTML ```{
  "provider": "openai-codex",
  "model": "gpt-5.4",
  "outputs": [
    {
      "text": "<html>\n  <head>\n    <meta name=\"viewport\" content=\"width=device-width, initial-scale=1\" />\n    <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex-direction:column;gap:2rem;height:100%;justify-content:center;width:100%}@keyframes enlarge-appear{0%{opacity:0;transform:scale(75%) rotate(-90deg)}to{opacity:1;transform:scale(100%) rotate(0deg)}}.logo{color:#8e8ea0}.scale-appear{animation:enlarge-appear .4s ease-out}@media (min-width:768px){.scale-appear{height:48px;width:48px}}.data:empty{display:none}.data{border-radius:5px;color:#8e8ea0;text-…",
      "mediaUrl": null
    }
  ]
}```

scenic fernBOT Apr 16, 2026, 10:14 AM

#

Perfect isolation, yes, this confirms it. ✅

You have a Codex route failure (HTML returned from openai-codex/gpt-5.4), while Ollama is healthy.
So the hanging/queueing is from that provider path, not your bootstrap tuning.

Recommended next step

Please open a dedicated bug with exactly those two repro outputs:

infer with Ollama returns normal text
infer with openai-codex/gpt-5.4 returns HTML

Issue tracker: https://github.com/openclaw/openclaw/issues

Immediate workaround

Use Ollama (or another non-Codex provider) as default for now so chat is usable:

#

openclaw models set ollama/gemma4:31b-cloud

If you want, I can help you draft a clean 10-line bug report body from what you already collected.

brisk fog Apr 16, 2026, 10:15 AM

#

sounds good, that will help with the quality of the bug report

scenic fernBOT Apr 16, 2026, 10:15 AM

#

Awesome, here’s a clean bug report draft you can paste:

Title
openai-codex/gpt-5.4 returns HTML payload instead of model output (webchat/TUI hangs, messages queue)

Body

Environment

OpenClaw: 2026.4.14
Default model: openai-codex/gpt-5.4
Surface: Dashboard webchat + TUI

Repro