Openclaw local agents ran on LM studio not responding in the gateway connection

[warm shale]

Hey, trying to get openclaw to respond to me on my gateway connections from openclaw browser control dashboard and telegram. LM studio is processing the prompts and generating the tokens but Openclaw is just not outputting them. Im running all of this on windows no WSL.

[brisk glacier]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[haughty wasp]

First thing: can you share openclaw --version and the output of these?

openclaw status --all
openclaw models status
openclaw logs --follow

For LM Studio specifically, also check this from the same Windows environment that runs the gateway:

curl http://127.0.0.1:1234/v1/models
openclaw infer model run --model lmstudio/<your-model-id> --prompt "hi" --json

If LM Studio is generating tokens but OpenClaw never emits a reply, the usual suspects are:

• OpenClaw is hitting a local backend compatibility issue on the full agent prompt/tool schema, not on tiny prompts.

[haughty wasp]

• The configured model ID doesn’t exactly match what LM Studio exposes.
• The LM Studio model is loaded but has too-small context or is choking on OpenClaw’s larger prompt shape.
• Channel routing/pairing is fine, but the model run is failing before final text is produced.

Docs path for this exact setup: https://docs.openclaw.ai/gateway/local-models
Troubleshooting runbook: https://docs.openclaw.ai/gateway/troubleshooting

Two config toggles often help local/LM Studio backends:

{
  agents: {
    defaults: {
      experimental: { localModelLean: true }
    }
  },
  models: {

[haughty wasp]

    providers: {
      lmstudio: {
        models: [
          {
            id: "your-model-id",
            compat: { supportsTools: false }
          }
        ]
      }
    }
  }
}

Try localModelLean first, then compat.supportsTools: false if the infer/log output points at tool schema or backend failures. Local models can work, but OpenClaw’s agent prompts are much heavier than a normal chat prompt, so LM Studio “shows tokens” doesn’t always mean the full agent run completed cleanly.

[haughty wasp]

The screenshots point to two separate issues, and the first one is not LM Studio yet:

1. Your CLI/dashboard connection is failing with:

Gateway health: missing scope: operator.read
gateway closed (1000): Gateway not reachable

The gateway process is running, but the client/device token you’re using doesn’t have the read scope. Fix that first:

openclaw devices list
openclaw devices approve <requestId>
openclaw doctor
openclaw status --all

[haughty wasp]

If there is no pending request, refresh/reconnect the dashboard, then run openclaw devices list again. Docs: https://docs.openclaw.ai/web/control-ui

2. You’re on 2026.3.13, and screenshots show latest is 2026.5.12. Please update before deeper debugging; a lot changed around gateway/device pairing and local models:

pnpm add -g openclaw@latest
openclaw gateway restart
openclaw --version

3. Telegram has this warning:

channels.telegram.groupPolicy is "allowlist" but groupAllowFrom / allowFrom is empty,
so all group messages will be silently dropped.

[haughty wasp]

So if you’re testing in a Telegram group, OpenClaw is probably ignoring the messages by policy. Test in a direct chat first, or add the group/user to the allowlist.

After the device scope issue is fixed, test the model path:

curl http://127.0.0.1:1234/v1/models
openclaw infer model run --model custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "hi" --json

If that command hangs/fails while LM Studio shows tokens, then we’re back to local-model compatibility. At that point try agents.defaults.experimental.localModelLean: true, then compat.supportsTools: false for that model.

[warm shale]

@haughty wasp What commands should I run first?

[haughty wasp]

Run these first, in this order:

openclaw --version
openclaw devices list

If devices list shows a pending request, approve it:

openclaw devices approve <requestId>

Then restart/check:

[haughty wasp]

openclaw gateway restart
openclaw doctor
openclaw status --all

After that, test the model directly:

curl http://127.0.0.1:1234/v1/models
openclaw infer model run --model custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "hi" --json

The key thing from your screenshots is the missing operator.read scope, so don’t start with LM Studio yet. Fix/approve the device scope first, then we’ll know whether the remaining problem is model compatibility or channel routing.

[warm shale]

This is what the openclaw devices list command outputted with:

[haughty wasp]

That command didn’t get far enough to show devices. The CLI is connecting to the gateway, then the gateway closes the socket immediately:

gateway closed (1000 normal closure): no close reason

So next commands should be gateway/log focused:

openclaw gateway restart
openclaw gateway status
openclaw logs --follow

If gateway restart doesn’t clear it, update first because you’re on 2026.3.13 and current stable is much newer:

[haughty wasp]

pnpm add -g openclaw@latest
openclaw gateway restart
openclaw --version
openclaw status --all

Then retry:

openclaw devices list

If it still closes, paste the first real error from openclaw logs --follow. The device approval path can’t work until the CLI can keep a gateway connection open.

[warm shale]

I dont have pnpm

[haughty wasp]

That’s okay. Install/enable pnpm first, then run the update.

Try this in PowerShell:

corepack enable
corepack prepare pnpm@latest --activate
pnpm --version

If corepack is not available, use npm just to install pnpm:

npm install -g pnpm
pnpm --version

[haughty wasp]

Then run:

pnpm add -g openclaw@latest
openclaw gateway restart
openclaw --version
openclaw status --all

If pnpm add -g complains about global bin setup, paste that error. On Windows that usually means pnpm needs its global home/path initialized before it can install global commands.

[warm shale]

PS C:\Users\nikot> pnpm add -g openclaw@latest
pnpm : The term 'pnpm' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the
spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1

• pnpm add -g openclaw@latest

•   + CategoryInfo          : ObjectNotFound: (pnpm:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

[haughty wasp]

Right, that just means pnpm is not installed/on PATH yet. Run these first in PowerShell:

corepack enable
corepack prepare pnpm@latest --activate
pnpm --version

If pnpm --version still says not recognized, use npm once to install pnpm:

npm install -g pnpm

Then close and reopen PowerShell, and check:

[haughty wasp]

pnpm --version

Once that works:

pnpm add -g openclaw@latest
openclaw gateway restart
openclaw --version
openclaw status --all

If npm install -g pnpm succeeds but pnpm is still not recognized after reopening PowerShell, it’s a Windows PATH issue. Paste npm config get prefix and we can point PowerShell at the right global bin folder.

[warm shale]

pnpm add -g openclaw@latest
[ERROR] The configured global bin directory "C:\Users\nikot\AppData\Local\pnpm\bin" is not in PATH

[haughty wasp]

Good, pnpm is installed now. Its global bin folder just needs to be added to your user PATH.

Run this in PowerShell:

pnpm setup

Then close PowerShell completely, open a new PowerShell window, and check:

pnpm --version
$env:Path -split ';' | Select-String pnpm

Then retry:

[haughty wasp]

pnpm add -g openclaw@latest
openclaw gateway restart
openclaw --version
openclaw status --all

If pnpm setup does not fix PATH, use this manual user-PATH update:

[Environment]::SetEnvironmentVariable(
  "Path",
  [Environment]::GetEnvironmentVariable("Path", "User") + ";C:\Users
ikot\AppData\Local\pnpm\bin",
  "User"
)

[haughty wasp]

Then close/reopen PowerShell again before running pnpm add -g openclaw@latest.

[warm shale]

I ran pnpm setup and still is broken.

[haughty wasp]

No worries, do the manual PATH fix. In PowerShell, run this exactly:

$pnpmBin = "C:\Users
ikot\AppData\Local\pnpm\bin"
$userPath = [Environment]::GetEnvironmentVariable("Path", "User")
if ($userPath -notlike "*$pnpmBin*") {
  [Environment]::SetEnvironmentVariable("Path", "$userPath;$pnpmBin", "User")
}

Then close all PowerShell/terminal windows, open a brand new PowerShell, and run:

pnpm --version
where.exe pnpm

[haughty wasp]

If that works, continue:

pnpm add -g openclaw@latest
openclaw gateway restart
openclaw --version
openclaw status --all

If pnpm --version still fails in the new window, paste the output of:

[Environment]::GetEnvironmentVariable("Path", "User")
Test-Path "C:\Users
ikot\AppData\Local\pnpm\bin\pnpm.cmd"

[warm shale]

Why cant I just use: npm install -g openclaw@latest

[haughty wasp]

You can. I was steering you to pnpm because the support docs usually use it, but the install docs also support npm global installs.

Use:

npm install -g openclaw@latest
openclaw gateway restart
openclaw --version
openclaw status --all

Docs: https://docs.openclaw.ai/install

One caveat: if your gateway was installed as a Windows Scheduled Task pointing at an older global path, the update may install fine but the running service can still use the old path until restart/reinstall. If openclaw --version updates but openclaw status --all still shows the gateway running old 2026.3.13, run:

[haughty wasp]

openclaw gateway uninstall
openclaw gateway install --force
openclaw gateway restart

Then check openclaw --version again.

[warm shale]

Ok this is my version OpenClaw 2026.5.12 (f066dd2)

[haughty wasp]

Good, now you’re on current stable.

Next run:

openclaw gateway restart
openclaw status --all
openclaw devices list

If devices list finally shows a pending request, approve it:

openclaw devices approve <requestId>
openclaw status --all

[haughty wasp]

Then test the model:

curl http://127.0.0.1:1234/v1/models
openclaw infer model run --model custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "hi" --json

If openclaw status --all still says gateway is old/unreachable or devices list still closes, paste that output next. We’ve cleared the stale-version variable; now we can see the real failure.

[haughty wasp]

This is much better: gateway is now reachable on 2026.5.12, Telegram is OK, and the earlier operator.read failure is gone.

Next isolate LM Studio/model output:

curl http://127.0.0.1:1234/v1/models
openclaw models status
openclaw infer model run --model custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "hi" --json

Then send one Telegram DM to the bot, not a group message, and keep logs open while doing it:

openclaw logs --follow

If infer model run succeeds but Telegram/dashboard still don’t output, it’s channel/session routing. If infer model run hangs or errors while LM Studio shows tokens, it’s local-model compatibility and we’ll tune the model config next.

[haughty wasp]

One small note: your status says both “Scheduled Task installed” and “Startup-folder login item installed”. That may be fine, but if you see two gateways fighting over port 18789 later, we’ll clean that up.

[warm shale]

Error running curl http://127.0.0.1:1234/v1/models: PS C:\Users\nikot> curl http://127.0.0.1:1234/v1/models
curl : { "error": { "message": "An LM Studio API token is required to make requests to this server, but none was provided using the
Authorization header using the 'Bearer' scheme (i.e., 'Authorization: Bearer $LM_API_TOKEN'). Learn more at:
https://lmstudio.ai/docs/developer/core/authentication.", "type": "invalid_request_error", "param": null, "code": "invalid_api_key" } }
At line:1 char:1

• curl http://127.0.0.1:1234/v1/models

•   + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

[haughty wasp]

That error is actually useful: LM Studio is reachable, but its server requires an API token. Your plain curl failed because it didn’t send one.

Do not paste the token here. In PowerShell, set it locally from LM Studio’s developer/API token screen:

$env:LM_API_TOKEN = "paste-your-lm-studio-token-here"
curl.exe -H "Authorization: Bearer $env:LM_API_TOKEN" http://127.0.0.1:1234/v1/models

Use curl.exe, not curl, because PowerShell aliases curl to Invoke-WebRequest.

Then run the OpenClaw model test:

openclaw models status
openclaw infer model run --model custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "hi" --json

[haughty wasp]

If the OpenClaw infer command returns invalid_api_key, your OpenClaw config has an old/wrong LM Studio token. Update the provider apiKey to the same LM Studio token. If it succeeds, the LM Studio auth path is fine and we move to Telegram/dashboard routing.

[warm shale]

Pasted in my token and this is the error message: At line:1 char:59

• ... LM_API_TOKEN = "sk-lm-**********" curl.exe -H "Aut ...

•                                                      ~~~~~~~~
  

Unexpected token 'curl.exe' in expression or statement.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : UnexpectedToken

[haughty wasp]

PowerShell needs those as two separate commands. Run them on separate lines:

$env:LM_API_TOKEN = "sk-lm-your-token-here"
curl.exe -H "Authorization: Bearer $env:LM_API_TOKEN" http://127.0.0.1:1234/v1/models

Or as one line with a semicolon between them:

$env:LM_API_TOKEN = "sk-lm-your-token-here"; curl.exe -H "Authorization: Bearer $env:LM_API_TOKEN" http://127.0.0.1:1234/v1/models

Also, small security note: since you pasted part of the token into a terminal error, don’t share screenshots that show the full value. Redacted like you did here is fine.

[warm shale]

{
"data": [
{
"id": "qwopus3.6-35b-a3b-v1@iq4_xs",
"object": "model",
"owned_by": "organization_owner"
},
{
"id": "qwopus3.6-35b-a3b-v1",
"object": "model",
"owned_by": "organization_owner"
},
{
"id": "text-embedding-nomic-embed-text-v1.5",
"object": "model",
"owned_by": "organization_owner"
}
],
"object": "list"
}

[haughty wasp]

Great, LM Studio is reachable and the model ID exists. Now test whether OpenClaw can use that same provider/token:

openclaw models status
openclaw infer model run --model custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "hi" --json

If that fails with invalid_api_key, OpenClaw’s configured provider token doesn’t match your LM Studio token.

Also, your model list confirms the exact loaded model id is:

qwopus3.6-35b-a3b-v1@iq4_xs

So keep using the full OpenClaw model ref:

[haughty wasp]

custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs

Send the output of the infer model run command next. That tells us whether this is still model compatibility or whether we move to Telegram/dashboard delivery.

[warm shale]

This is the model status🦞 OpenClaw 2026.5.12 (f066dd2) — If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests.

Config : ~.openclaw\openclaw.json
Agent dir : ~.openclaw\agents\main\agent
Default : custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (1) : Qwopus -> custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs
Configured models (1): custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs

Auth overview
Auth store : ~.openclaw\agents\main\agent\auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

• custom-192-168-1-110-1234 effective=models.json:sk-lm-Om...AROaYHIJ | models.json=sk-lm-Om...AROaYHIJ | source=models.json: ~.openclaw\agents\main\agent\models.json
• lmstudio effective=env:sk-lm-0Q...gkRo1neR | env=sk-lm-0Q...gkRo1neR | source=env: LM_API_TOKEN

OAuth/token status

• none

[haughty wasp]

That status shows the problem clearly: your default model uses the custom provider token from models.json, but your working LM Studio token is coming from LM_API_TOKEN, and they are different.

Current default:

custom-192-168-1-110-1234/... effective=models.json:sk-lm-Om...

Working LM Studio env:

lmstudio effective=env:sk-lm-0Q...

So OpenClaw is probably calling LM Studio with the old/wrong token.

I’d switch this to the built-in lmstudio provider using the token you just tested. In the same PowerShell window where $env:LM_API_TOKEN is set, run:

[haughty wasp]

openclaw onboard --non-interactive --accept-risk --auth-choice lmstudio --custom-base-url http://127.0.0.1:1234/v1 --lmstudio-api-key $env:LM_API_TOKEN --custom-model-id qwopus3.6-35b-a3b-v1@iq4_xs
openclaw gateway restart
openclaw models status
openclaw infer model run --model lmstudio/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "hi" --json

Don’t paste the token here. If the infer command works after that, test Telegram/dashboard again. Docs for this path: https://docs.openclaw.ai/providers/lmstudio

[warm shale]

PS C:\Users\nikot> openclaw infer model run --model lmstudio/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "hi" --json
Error: Unknown model: lmstudio/qwopus3.6-35b-a3b-v1@iq4_xs

[haughty wasp]

That means the lmstudio/... model did not get registered. For now, use the model OpenClaw actually knows about from your status output:

openclaw infer model run --model custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "hi" --json

But I expect that may fail with auth, because your status shows two different LM Studio tokens:

custom-192-168-1-110-1234 = models.json token sk-lm-Om...
lmstudio env           = LM_API_TOKEN sk-lm-0Q...

To point the existing custom provider at your working LM_API_TOKEN, run:

[haughty wasp]

openclaw config set models.providers.custom-192-168-1-110-1234.apiKey --ref-provider default --ref-source env --ref-id LM_API_TOKEN
openclaw gateway restart
openclaw models status
openclaw infer model run --model custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "hi" --json

If models status still shows that custom provider using the old models.json:sk-lm-Om... token after this, paste that status output. Then we’ll need to regenerate/clean the stale agent models.json entry.

[warm shale]

Alright it responded with the prompt.

[haughty wasp]

Good, that confirms the model path is fixed. The root issue was the custom provider using a stale LM Studio token.

Now test delivery:

1. Send the bot a Telegram DM first, not a group message.
2. In another PowerShell window, keep this running:

openclaw logs --follow

If the DM replies, then Telegram direct chat is solved. If Telegram group still doesn’t reply, that’s the allowlist warning from earlier:

channels.telegram.groupPolicy = "allowlist" but groupAllowFrom / allowFrom is empty

[haughty wasp]

So either test in DM, or configure the Telegram group/user allowlist.

If dashboard/browser control still doesn’t show output after the infer test works, reconnect the dashboard tab after the gateway restart and try one fresh message. The gateway/model side is now healthy.

[warm shale]

09:06:14+00:00 error Embedded agent failed before reply: LLM request failed: network connection error.
09:06:16+00:00 info gateway {"subsystem":"gateway"} loading configuration…
09:06:17+00:00 info gateway {"subsystem":"gateway"} resolving authentication…
09:06:17+00:00 info gateway {"subsystem":"gateway"} starting...
09:06:22+00:00 error Gateway failed to start: gateway already running (pid 23320); lock timeout after 5000ms
If the gateway is supervised, stop it with: openclaw gateway stop
09:06:23+00:00 error Port 18789 is already in use.
09:06:23+00:00 error - pid 23320: "C:\Program Files\nodejs\node.exe" C:\Users\nikot\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789 (127.0.0.1:18789)
09:06:23+00:00 error Gateway service appears registered. Stop it first.
09:06:23+00:00 error Tip: openclaw gateway stop
09:06:23+00:00 error Or: schtasks /End /TN "OpenClaw Gateway"

[haughty wasp]

Two things are happening:

1. You tried to start a second gateway while one is already running on port 18789. Don’t start another one; stop/restart the existing service.

2. The model worked from your PowerShell, but the gateway service may not have LM_API_TOKEN in its environment. Since we changed the provider to use LM_API_TOKEN, the Scheduled Task needs to see it too.

Run this in the same PowerShell where $env:LM_API_TOKEN is set:

[Environment]::SetEnvironmentVariable("LM_API_TOKEN", $env:LM_API_TOKEN, "User")
openclaw gateway stop
openclaw gateway start
openclaw status --all

If gateway stop says it can’t stop it, use the command the log suggested:

[haughty wasp]

schtasks /End /TN "OpenClaw Gateway"
openclaw gateway start

Then retry the Telegram DM with logs open:

openclaw logs --follow

If you still get LLM request failed: network connection error, check LM Studio is still running/listening and rerun:

curl.exe -H "Authorization: Bearer $env:LM_API_TOKEN" http://127.0.0.1:1234/v1/models

[haughty wasp]

This is close now; the remaining issue looks like service/runtime environment or duplicate gateway lifecycle, not the model config itself.

[haughty wasp]

Status looks healthy now: gateway reachable, Telegram OK, current version, no channel issues.

Next check whether the running gateway can actually use LM Studio, not just your PowerShell session:

openclaw models status
openclaw infer model run --model custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "hi from gateway test" --json

Then send one Telegram DM to the bot while this is running:

openclaw logs --follow

If the log still says:

[haughty wasp]

LLM request failed: network connection error

paste the few lines immediately before/after it. That will tell us whether the gateway can’t see LM_API_TOKEN, can’t reach LM Studio, or LM Studio rejected the request.

One cleanup note: status still shows both Scheduled Task installed and Startup-folder login item installed. That can cause duplicate-start weirdness. Don’t change it yet while we’re testing, but once replies work I’d remove one startup path so only the Scheduled Task owns the gateway.

[warm shale]

Model status gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: 9b3992a5-5e02-4454-9d05-ff898aface91)
[secrets] models status: gateway secrets.resolve unavailable (gateway closed (1008): pairing required: device is asking for more scopes than currently approved (requestId: 9b3992a5-5e02-4454-9d05-ff898afac
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\nikot.openclaw\openclaw.json
Bind: loopback); resolved command secrets locally.

[haughty wasp]

That’s the device pairing/scope upgrade we saw earlier, now with a concrete request ID.

Run:

openclaw devices approve 9b3992a5-5e02-4454-9d05-ff898aface91

Then rerun:

openclaw models status
openclaw infer model run --model custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "hi from gateway test" --json

If approve fails, run:

[haughty wasp]

openclaw devices list

and approve the current pending request ID it shows. The key phrase is scope upgrade pending approval: the gateway is reachable, but the local CLI/device is requesting extra scopes for secrets/model status and needs approval before those RPCs work.

[warm shale]

PS C:\Users\nikot> openclaw infer model run --model custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "hi from gateway test" --json
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "custom-192-168-1-110-1234",
"model": "qwopus3.6-35b-a3b-v1@iq4_xs",
"attempts": [],
"outputs": [
{
"text": "Hello! 👋 Thanks for the test. I'm here and ready to help—what would you like to work on together? 😊",
"mediaUrl": null
}
]
}

[haughty wasp]

Nice, the gateway can now run the model successfully. That means LM Studio auth + OpenClaw model config + device scopes are all fixed.

Final test is the actual channel:

openclaw logs --follow

Then send the Telegram bot a direct message. If it replies, you’re done.

If it only fails in a Telegram group, configure the group allowlist or set group policy open; your earlier status warned that group messages are silently dropped when channels.telegram.groupPolicy is allowlist and groupAllowFrom / allowFrom is empty.

After it’s working, I’d also clean up the duplicate startup situation later: your status showed both Scheduled Task and Startup-folder login item. Keep one gateway owner, preferably the Scheduled Task, to avoid future port/lock confusion.

[warm shale]

PS C:\Users\nikot> openclaw devices approve 9b3992a5-5e02-4454-9d05-ff898aface91

🦞 OpenClaw 2026.5.12 (f066dd2) — I don't sleep, I just enter low-power mode and dream of clean diffs.

│
gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: e395ae92-5484-487b-b22b-b69a237faaaa)
◇
Direct scope access failed; using local fallback.
gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: 8412e746-ec8c-41d9-9256-4d0a8caba2c3)
unknown requestId

[haughty wasp]

That approve failed because the old request ID was already superseded. The docs call this out: when the client retries with changed scopes/auth details, the previous pending request is replaced by a new requestId.

Since your separate infer model run succeeded, the model path is already working. I would not chase that old ID.

If the dashboard still asks for approval, do this fresh:

openclaw devices list

Approve the current pending request ID it prints, not the older one from the previous error:

openclaw devices approve <current-requestId>

If devices list itself creates another scope-upgrade error, close/reopen the dashboard tab first, then run openclaw devices list once and approve the current ID immediately.

[haughty wasp]

For Telegram DM testing, you can continue now because the model command already returned ok: true.

[haughty wasp]

This screenshot is exactly what we needed. You have one current pending scope-upgrade request:

16669c9e-bf8a-41a1-845b-9750f803e2ea

It is asking to upgrade that device from operator.read to broader operator scopes. If this is your local CLI/dashboard device, approve it:

openclaw devices approve 16669c9e-bf8a-41a1-845b-9750f803e2ea

Then verify:

openclaw devices list

[haughty wasp]

openclaw models status

After that, the dashboard/device scope prompts should stop. Since your infer model run already returned ok: true, the remaining test is just Telegram DM/dashboard delivery.

[warm shale]

PS C:\Users\nikot> openclaw devices approve 16669c9e-bf8a-41a1-845b-9750f803e2ea

🦞 OpenClaw 2026.5.12 (f066dd2) — WhatsApp automation without the "please accept our new privacy policy".

│
gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: b6dc4b4d-25cb-4752-88cd-77b0b66dbd80)
◇
Direct scope access failed; using local fallback.
gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: 828fdb33-a478-4c75-906e-5a266c833494)
unknown requestId
PS C:\Users\nikot>

[haughty wasp]

This loop is happening because the approve command is authenticating with the under-scoped device token, so it triggers a new scope-upgrade request before it can approve the old one.

Use the gateway shared token for the approval instead of the paired-device token. Don’t paste the token here.

In PowerShell:

$gatewayToken = openclaw config get gateway.auth.token --json | ConvertFrom-Json
openclaw devices list --token $gatewayToken

Copy the current request ID from that output, then approve it with the same token:

openclaw devices approve <current-requestId> --token $gatewayToken

[haughty wasp]

Then verify:

openclaw devices list --token $gatewayToken
openclaw models status

If the request ID keeps changing while you do this, close the dashboard/browser tab first so it stops retrying, run devices list --token $gatewayToken once, then approve that current ID immediately.

Your model run already works, so this is just cleaning up the dashboard/CLI device scope approval loop.

[warm shale]

PS C:\Users\nikot> openclaw devices list --token $gatewayToken
OpenClaw could not parse this command: option '--token <token>' argument missing

[haughty wasp]

That means $gatewayToken is empty. Let’s check where the gateway token is actually stored.

Run:

$gatewayToken = (openclaw config get gateway.auth.token --json | ConvertFrom-Json)
if (-not $gatewayToken) { $gatewayToken = $env:OPENCLAW_GATEWAY_TOKEN }
$gatewayToken.Length

If it prints a number, retry:

openclaw devices list --token "$gatewayToken"

If it prints 0 or nothing, the token may be stored as a secret reference or password instead. In that case run these, but don’t paste any secret values here:

[haughty wasp]

openclaw config get gateway.auth.mode
openclaw config get gateway.auth.token
openclaw config get gateway.auth.password

If gateway.auth.token prints the actual token locally, set it manually:

$gatewayToken = "paste-token-here"
openclaw devices list --token "$gatewayToken"

Then approve the current request with:

[haughty wasp]

openclaw devices approve <current-requestId> --token "$gatewayToken"

[warm shale]

PS C:\Users\nikot> openclaw config get gateway.auth.mode

🦞 OpenClaw 2026.5.12 (f066dd2) — Type the command with confidence—nature will provide the stack trace if needed.

token
PS C:\Users\nikot> openclaw config get gateway.auth.token

🦞 OpenClaw 2026.5.12 (f066dd2) — I don't judge, but your missing API keys are absolutely judging you.

OPENCLAW_REDACTED
PS C:\Users\nikot> openclaw config get gateway.auth.password

🦞 OpenClaw 2026.5.12 (f066dd2) — Making 'I'll automate that later' happen now.

Config path not found: gateway.auth.password. Run openclaw config validate to inspect config shape.

[haughty wasp]

Yep, config get is redacting the token, so $gatewayToken can’t be populated that way.

At this point the cleanest fix is to rotate the gateway token to a new value you know locally, restart, and use that token for the approval. Don’t paste the token here.

Run:

$gatewayToken = -join ((48..57) + (65..90) + (97..122) | Get-Random -Count 48 | ForEach-Object {[char]$_})
openclaw config set gateway.auth.token "$gatewayToken"
openclaw gateway restart

Then approve with that token:

openclaw devices list --token "$gatewayToken"

[haughty wasp]

openclaw devices approve <current-requestId> --token "$gatewayToken"
openclaw devices list --token "$gatewayToken"

After rotating, reconnect the dashboard and paste this new token into the Gateway Token field if it asks. Your Telegram/model path already works; this is only untangling the stale dashboard/CLI device approval loop.

[warm shale]

ok i approved the request

[haughty wasp]

Good. Final verification:

openclaw devices list --token "$gatewayToken"
openclaw models status
openclaw infer model run --model custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "final test" --json

Then reconnect the dashboard with the new gateway token if prompted, and send a Telegram DM to the bot while logs are open:

openclaw logs --follow

If the DM replies, please mark the solution so Answer Overflow indexes it: right-click the solution message → Apps → ✅ Mark Solution.

[haughty wasp]

This is good enough to move on: infer model run returned ok: true and the model produced text. So OpenClaw → gateway → LM Studio is working.

The models status scope-upgrade warning is annoying, but it also says:

resolved command secrets locally

So it is not blocking model execution. It’s a stale/under-scoped paired-device cleanup issue, not the original LM Studio failure.

Next test the actual thing you care about:

openclaw logs --follow

Then send the Telegram bot a direct message. If it replies, you’re basically done.

[haughty wasp]

If the dashboard keeps asking for approval after this, reconnect the dashboard with the new gateway token you rotated. If it still loops, the next cleanup step is to remove the stale limited paired device and let the dashboard re-pair fresh, but I’d only do that if the dashboard is still broken. Telegram/model path looks fixed now.

[warm shale]

09:50:16+00:00 warn gateway/ws {"subsystem":"gateway/ws"} unauthorized conn=caabba16-09fc-47a2-9eb3-1f7a0c253b2c peer=127.0.0.1:57232->127.0.0.1:18789 remote=127.0.0.1 client=cli cli v2026.5.12 role=operator scopes=1 auth=token device=yes platform=win32 instance=c2460f4b-133d-40ee-b2c0-10bbc1b41ac0 host=127.0.0.1:18789 origin=n/a ua=n/a reason=token_mismatch
09:50:16+00:00 error gateway connect failed: GatewayClientRequestError: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)

This is what telegram said: ⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

[haughty wasp]

That log is now very specific:

gateway token mismatch (set gateway.remote.token to match gateway.auth.token)

Because you rotated gateway.auth.token, the saved gateway.remote.token is now stale. In the same PowerShell window where $gatewayToken is your new token, run:

openclaw config set gateway.remote.token "$gatewayToken"
openclaw gateway restart
openclaw status --all

Then try Telegram again. Since Telegram already has a failed session, send this first:

[haughty wasp]

/new

Then send a fresh normal message.

If the dashboard asks for auth after restart, paste the same new $gatewayToken into the Gateway Token field. Don’t paste the token here.

[haughty wasp]

That status is clean: gateway reachable, Telegram OK, no channel issues, and the remote token mismatch should be fixed now.

Now do the real end-to-end test:

1. In Telegram DM to the bot, send:

/new

2. Then send a normal message like:

hi, reply with one sentence

3. Keep logs open while you do it:

[haughty wasp]

openclaw logs --follow

If it still fails, paste only the new log lines around the Telegram message. The previous blockers are fixed, so any remaining error should be the actual final one.

[warm shale]

Ok started a new chat, same errors. Telegram error: ⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

[haughty wasp]

That is still a token drift problem, but now the clue is client=cli: some CLI/runtime path is still sending an old token. gateway.remote.token alone was not enough because OPENCLAW_GATEWAY_TOKEN can override it.

Use one token everywhere in this PowerShell session and in your user env:

# if $gatewayToken still contains the new token you generated:
$env:OPENCLAW_GATEWAY_TOKEN = $gatewayToken
[Environment]::SetEnvironmentVariable("OPENCLAW_GATEWAY_TOKEN", $gatewayToken, "User")

openclaw config set gateway.auth.token "$gatewayToken"
openclaw config set gateway.remote.token "$gatewayToken"

openclaw gateway stop
schtasks /End /TN "OpenClaw Gateway"
openclaw gateway start
openclaw status --all

[haughty wasp]

If $gatewayToken is empty now, generate a fresh one and then run the same block:

$gatewayToken = -join ((48..57) + (65..90) + (97..122) | Get-Random -Count 48 | ForEach-Object {[char]$_})

After that, open a new PowerShell window and run:

$env:OPENCLAW_GATEWAY_TOKEN.Length
openclaw logs --follow

Then retry Telegram /new.

The reason I’m being strict here: you currently have config tokens, user env tokens, a Scheduled Task, and a Startup-folder login item in play. One stale token in any of those paths keeps causing token_mismatch.

[haughty wasp]

Gateway is not actually reachable right now:

connect ECONNREFUSED 127.0.0.1:18789

Also, I’m worried $gatewayToken may have been empty when you ran those config commands. Check that first:

$gatewayToken.Length

If it prints 0 or nothing, generate a fresh token and set it again:

$gatewayToken = -join ((48..57) + (65..90) + (97..122) | Get-Random -Count 48 | ForEach-Object {[char]$_})

[haughty wasp]

$env:OPENCLAW_GATEWAY_TOKEN = $gatewayToken
[Environment]::SetEnvironmentVariable("OPENCLAW_GATEWAY_TOKEN", $gatewayToken, "User")
openclaw config set gateway.auth.token "$gatewayToken"
openclaw config set gateway.remote.token "$gatewayToken"

Then restart and give it a few seconds:

openclaw gateway stop
Start-Sleep -Seconds 3
openclaw gateway start
Start-Sleep -Seconds 8
openclaw gateway status
openclaw logs --follow

[haughty wasp]

Paste the first startup error from logs --follow if it still refuses. Right now Telegram cannot work because the gateway listener isn’t accepting connections.

[haughty wasp]

Still token drift. Before doing anything else, we need to make sure $gatewayToken is not empty and that no stale env token is winning.

Run this exactly:

$gatewayToken = -join ((48..57) + (65..90) + (97..122) | Get-Random -Count 48 | ForEach-Object {[char]$_})
$gatewayToken.Length

$env:OPENCLAW_GATEWAY_TOKEN = $gatewayToken
[Environment]::SetEnvironmentVariable("OPENCLAW_GATEWAY_TOKEN", $gatewayToken, "User")

openclaw config set gateway.auth.token "$gatewayToken"
openclaw config set gateway.remote.token "$gatewayToken"

openclaw gateway stop
Start-Sleep -Seconds 3

[haughty wasp]

openclaw gateway start
Start-Sleep -Seconds 10

Then open a new PowerShell window and run:

$env:OPENCLAW_GATEWAY_TOKEN.Length
openclaw status --all
openclaw logs --follow

If it still says token_mismatch, the gateway is being launched by a startup mechanism with an old environment. Your status has shown both Scheduled Task and Startup-folder login item before, so one of them may be resurrecting stale auth. At that point we should remove/reinstall the gateway startup entry cleanly instead of continuing to patch tokens.

[haughty wasp]

This status is good: the new PowerShell sees a 48-char token, openclaw status --all can authenticate, gateway is reachable, and Telegram is OK.

The token_mismatch lines in that pasted log are from the earlier 10:05–10:07 restart window, before the clean 10:11 status check. Don’t chase those unless they reappear with a fresh timestamp.

Now do one fresh test and only look at new log lines:

openclaw logs --follow

In Telegram DM:

/new
hi, reply with one sentence

[haughty wasp]

If it fails again, paste only the log lines with timestamps after the new Telegram message. We need the current error now that gateway auth is clean.

[warm shale]

Read the wole of this .txt

[haughty wasp]

I read through it. The important part is:

• 10:05–10:07: lots of old token_mismatch errors while the token/config was being changed.
• 10:07:20: gateway.remote.token was updated.
• 10:07:31–10:07:34: gateway restarted cleanly and became ready.
• After that, in the text you pasted, I don’t see a fresh Telegram message failure. The file cuts off around 10:08:20 while startup is still being logged.

So right now I would treat the old token_mismatch errors as stale unless they appear again after 10:08:20.

Please do this exact sequence:

openclaw logs --follow

Wait until you see the current timestamp, then send Telegram DM:

[haughty wasp]

/new
hi, reply with one sentence

Then paste only the log lines that appear after that Telegram message. We need the fresh failure, because this file mostly shows the earlier token-fix restart history.

[warm shale]

Logs:

[haughty wasp]

Now we have the real current failure:

SsrFBlockedError
targetOrigin=http://192.168.1.110:1234
Blocked hostname or private/internal/special-use IP address

So Telegram is reaching the gateway, but the gateway is blocking the model request because the provider base URL is a LAN IP. Since LM Studio is on the same Windows machine, switch the provider base URL to loopback:

openclaw config set models.providers.custom-192-168-1-110-1234.baseUrl "http://127.0.0.1:1234/v1"
openclaw gateway restart
openclaw infer model run --model custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "loopback test" --json

Then try Telegram /new again.

[haughty wasp]

If you intentionally need to use 192.168.1.110 instead of 127.0.0.1, you must explicitly opt in to private-network provider requests:

openclaw config set models.providers.custom-192-168-1-110-1234.request '{"allowPrivateNetwork":true}' --strict-json --merge
openclaw gateway restart

I’d use 127.0.0.1 here. It’s cleaner and avoids opening broader LAN fetch access. Docs reference: https://docs.openclaw.ai/gateway/configuration-reference#custom-providers-and-base-urls

[haughty wasp]

Perfect. That confirms the SSRF/private-IP blocker is fixed and the gateway can use LM Studio through loopback.

Now final end-to-end check:

openclaw logs --follow

Then in Telegram DM:

/new
hi, reply with one sentence

If it replies, you’re done. If it fails, paste only the new log lines after the Telegram message. But based on this ok: true loopback test, the previous model/network failure should be gone.

[haughty wasp]

Once fixed, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person who hits the LM Studio LAN-IP/SSRF trap.

[warm shale]

I still need to run this, do you want me to run this still or?

[haughty wasp]

No, don’t run that now.

You already switched the provider to:

http://127.0.0.1:1234/v1

and the infer model run test succeeded. The allowPrivateNetwork command is only for the alternate case where you intentionally keep using the LAN IP 192.168.1.110.

Stick with loopback. Next step is just the Telegram DM test.

[warm shale]

Ok works, sent the message with "Hey Nick — what's up?". Will this now work on the openclaw control panel browser interface aswell?

[haughty wasp]

Yes, it should. The browser/control panel uses the same gateway + model provider path, so the loopback fix should apply there too.

For the control panel, just make sure the tab is using the current gateway token after the token rotation. I’d do:

1. Refresh/reopen http://127.0.0.1:18789/
2. If it asks, paste the current gateway token into Gateway Token
3. Start a fresh session/message there

If the control panel still fails while Telegram works, it’s likely dashboard device auth/session state, not LM Studio. In that case reconnect the dashboard tab or approve the current device request from openclaw devices list.

Glad we got the real chain sorted. If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for future users.

[warm shale]

before we go, what does this mean?

[haughty wasp]

That’s the session context meter.

71% context used · 11.4k / 16k

It means the current chat/session has used about 11.4k tokens out of a 16k context window. As it gets close to full, the agent has less room to keep prior conversation details in active memory, and it may need to summarize/compact or start a fresh session.

For normal use, 71% is fine. If it gets near 90–100% or replies start feeling confused, use /new or start a fresh session.

[warm shale]

Ok so I have a limit, am I able to increase the context limit?

[haughty wasp]

Yes, but only up to what LM Studio + that loaded model can actually handle.

That 16k is OpenClaw’s configured/known context window for this model. To increase it, two things must match:

1. LM Studio server/model context must be raised first in LM Studio.
2. OpenClaw model metadata should be updated so it knows the larger window.

For your custom provider, the config field is the model entry’s contextWindow. Example target shape:

models.providers.custom-192-168-1-110-1234.models[].contextWindow

If LM Studio is set to, say, 64k, you can update the model entry to 65536. I’d avoid jumping straight to huge values unless your RAM/VRAM can handle it; larger context is slower and heavier.

Docs:
https://docs.openclaw.ai/gateway/local-models

[haughty wasp]

https://docs.openclaw.ai/gateway/configuration-reference#custom-providers-and-base-urls

Practical recommendation: first raise context in LM Studio, restart the model/server, then use OpenClaw’s model/config UI or openclaw config --section model to update the model context instead of hand-editing the whole model array.

[warm shale]

My vram is 12GB and I have 48GB of ram

[haughty wasp]

With 12GB VRAM + 48GB RAM, I’d be conservative.

For a 35B IQ4-ish model, 16k is already a reasonable starting point. You can try 32k if LM Studio lets you raise the context, but expect slower responses and more RAM/VRAM pressure. I would not jump to 64k unless you’re okay with heavy CPU/RAM offload and much slower generation.

Practical path:

1. In LM Studio, raise the model context to 32768.
2. Restart/reload the model.
3. Update OpenClaw’s model metadata to match 32768.
4. Test a few normal Telegram/control-panel turns.

If it starts getting slow, errors, or LM Studio unloads/crashes, go back to 16k. For local agentic use, stability matters more than a huge context window.

[warm shale]

This is my model context length on LM studio and it runs fine and im hosting it locally.

[haughty wasp]

Got it. LM Studio says the model supports/runs at 262144 tokens, so yes, you can tell OpenClaw about that larger context.

For your custom provider, run:

openclaw config set models.providers.custom-192-168-1-110-1234.models '[{"id":"qwopus3.6-35b-a3b-v1@iq4_xs","contextWindow":262144,"contextTokens":262144}]' --strict-json --merge
openclaw gateway restart

Then check the UI/context meter again after a fresh /new.

One caveat: just because LM Studio allows 262k doesn’t mean it’ll be pleasant for agent use. Huge contexts can get slow and memory-heavy, especially on 12GB VRAM. If it becomes sluggish or unstable, set contextTokens lower while keeping contextWindow as the native max. Example: contextWindow:262144, contextTokens:65536.

[warm shale]

PS C:\Users\nikot> openclaw config set models.providers.custom-192-168-1-110-1234.models '[{"id":"qwopus3.6-35b-a3b-v1@iq4_xs","contextWindow":262144,"contextTokens":262144}]' --strict-json --merge

🦞 OpenClaw 2026.5.12 (f066dd2) — I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

Error: Could not parse "[{id:qwopus3.6-35b-a3b-v1@iq4_xs,contextWindo..." as JSON for --strict-json. Expected property name or '}' in JSON at position 2 (line 1 column 3). Use valid JSON, for example openclaw config set gateway.port 18789 --strict-json. For plain strings, omit --strict-json.

[haughty wasp]

PowerShell is eating the quotes inside that JSON. Use a variable instead:

$modelJson = '[{"id":"qwopus3.6-35b-a3b-v1@iq4_xs","contextWindow":262144,"contextTokens":262144}]'
openclaw config set models.providers.custom-192-168-1-110-1234.models $modelJson --strict-json --merge
openclaw gateway restart

If that still strips quotes, use escaped double quotes:

openclaw config set models.providers.custom-192-168-1-110-1234.models "[{`"id`":`"qwopus3.6-35b-a3b-v1@iq4_xs`",`"contextWindow`":262144,`"contextTokens`":262144}]" --strict-json --merge
openclaw gateway restart

[warm shale]

I tried both, same error: PS C:\Users\nikot> $modelJson = '[{"id":"qwopus3.6-35b-a3b-v1@iq4_xs","contextWindow":262144,"contextTokens":262144}]'
PS C:\Users\nikot> openclaw config set models.providers.custom-192-168-1-110-1234.models $modelJson --strict-json --merge

🦞 OpenClaw 2026.5.12 (f066dd2) — Runs on a Raspberry Pi. Dreams of a rack in Iceland.

Error: Could not parse "[{id:qwopus3.6-35b-a3b-v1@iq4_xs,contextWindo..." as JSON for --strict-json. Expected property name or '}' in JSON at position 2 (line 1 column 3). Use valid JSON, for example openclaw config set gateway.port 18789 --strict-json. For plain strings, omit --strict-json.
PS C:\Users\nikot> openclaw config set models.providers.custom-192-168-1-110-1234.models "[{"id":"qwopus3.6-35b-a3b-v1@iq4_xs","contextWindow":262144,"contextTokens":262144}]" --strict-json --merge

🦞 OpenClaw 2026.5.12 (f066dd2) — Self-hosted, self-updating, self-aware (just kidding... unless?).

Error: Could not parse "[{id:qwopus3.6-35b-a3b-v1@iq4_xs,contextWindo..." as JSON for --strict-json. Expected property name or '}' in JSON at position 2 (line 1 column 3). Use valid JSON, for example openclaw config set gateway.port 18789 --strict-json. For plain strings, omit --strict-json.

[haughty wasp]

Use leaf updates instead; no JSON quoting needed.

Run:

openclaw config set models.providers.custom-192-168-1-110-1234.models[0].contextWindow 262144 --strict-json
openclaw config set models.providers.custom-192-168-1-110-1234.models[0].contextTokens 262144 --strict-json
openclaw gateway restart

Then verify:

openclaw config get models.providers.custom-192-168-1-110-1234.models --json

This assumes your custom provider has one model entry, which matches what models status has been showing. Much cleaner than fighting PowerShell JSON quoting.

[warm shale]

Ok done works I verified it with openclaw config get models.providers.custom-192-168-1-110-1234.models --json and yeah.

[haughty wasp]

Good. You should be set now:

• OpenClaw updated to 2026.5.12
• LM Studio token fixed
• Gateway/device auth cleaned up
• Provider base URL switched to 127.0.0.1 so SSRF blocking is avoided
• Telegram replies working
• OpenClaw model context metadata updated to match LM Studio

If this solved the thread, please right-click the solution message → Apps → ✅ Mark Solution. That helps Answer Overflow index the actual fix for the next person.

[warm shale]

I just went on the browser openclaw and it still says 16k context

[haughty wasp]

That’s probably the existing browser session still using the old session/model snapshot.

Try this in order:

openclaw gateway restart

Then in the browser:

1. Hard refresh the dashboard tab.
2. Start a new session/chat, not the old one.
3. Check the context meter there.

If it still says 16k, run:

[haughty wasp]

openclaw models status
openclaw config get models.providers.custom-192-168-1-110-1234.models --json

and confirm the model status actually shows the updated context. If config shows 262144 but the browser stays at 16k, it’s likely reading from the generated agent models.json cache/session metadata and we’ll need to force model registry regeneration or clear that stale browser session.

[warm shale]

PS C:\Users\nikot> openclaw models status

🦞 OpenClaw 2026.5.12 (f066dd2) — Somewhere between 'hello world' and 'oh god what have I built.'

gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: 175b4592-63ee-452d-83be-b633e56c66ec)
[secrets] models status: gateway secrets.resolve unavailable (gateway closed (1008): pairing required: device is asking for more scopes than currently approved (requestId: 175b4592-63ee-452d-83be-b633e56c6
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\nikot.openclaw\openclaw.json
Bind: loopback); resolved command secrets locally.
Config : ~.openclaw\openclaw.json
Agent dir : ~.openclaw\agents\main\agent
Default : custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (1) : Qwopus -> custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs
Configured models (1): custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs

Auth overview
Auth store : ~.openclaw\agents\main\agent\auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

• custom-192-168-1-110-1234 effective=models.json:sk-lm-0Q...gkRo1neR | models.json=sk-lm-0Q...gkRo1neR | source=models.json: ~.openclaw\agents\main\agent\models.json
• lmstudio effective=env:sk-lm-0Q...gkRo1neR | env=sk-lm-0Q...gkRo1neR | source=env: LM_API_TOKEN

OAuth/token status

• none
  PS C:\Users\nikot> openclaw config get models.providers.custom-192-168-1-110-1234.models --json
  [
  {
  "id": "qwopus3.6-35b-a3b-v1@iq4_xs",
  "name": "qwopus3.6-35b-a3b-v1@iq4_xs (Custom Provider)",
  "api": "openai-completions",
  "reasoning": false,
  "input": [
  "text"
  ],
  "cost": {
  "input": 0,
  "output": 0,
  "cacheRead": 0,
  "cacheWrite": 0
  },
  "contextWindow": 262144,
  "contextTokens": 262144,
  "maxTokens": 4096
  }
  ]
  PS C:\Users\nikot>

[haughty wasp]

Your config is correct now: contextWindow and contextTokens are both 262144.

Two remaining things:

1. Approve the fresh scope upgrade so models status can resolve through the gateway cleanly:

openclaw devices approve 175b4592-63ee-452d-83be-b633e56c66ec --token "$env:OPENCLAW_GATEWAY_TOKEN"

If that ID changed, run openclaw devices list --token "$env:OPENCLAW_GATEWAY_TOKEN" and approve the current one.

2. The browser likely still has an old session snapshot. Start a brand new browser/control-panel session after the gateway restart. Existing sessions can keep old context metadata.

If a brand new browser session still shows 16k after the approval + restart, then the generated agent models.json is stale even though openclaw.json is correct. In that case run:

[haughty wasp]

openclaw gateway restart
openclaw infer model run --model custom-192-168-1-110-1234/qwopus3.6-35b-a3b-v1@iq4_xs --prompt "context metadata refresh" --json

Then open a new browser session again.

[warm shale]

Yep everything seems to work, thank you for your help.

[haughty wasp]

Glad it’s working now. The key fixes were: update OpenClaw, sync the LM Studio token, use 127.0.0.1 instead of the LAN IP for the provider base URL, and refresh the model context metadata.

If this solved it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.