Forem: member_0af6418a

Codex + Tencent LKEAP 401: It Was Not the Key

member_0af6418a — Mon, 18 May 2026 14:00:03 +0000

I ran into a failure that looked like an authentication problem at first:

unexpected status 401 Unauthorized

The setup was Codex against Tencent Cloud LKEAP Token Plan, using an OpenAI-compatible Chat Completions endpoint.

The important clue was not the 401. It was the final URL:

https://api.lkeap.cloud.tencent.com/plan/v3/chat/completions/responses

That URL shape is already wrong.

The config that caused it

The provider entry looked roughly like this:

[model_providers.custom]
name = "custom"
wire_api = "responses"
requires_openai_auth = true
base_url = "https://api.lkeap.cloud.tencent.com/plan/v3/chat/completions"

The mistake is subtle.

The Tencent endpoint in this setup is Chat Completions-style:

/plan/v3/chat/completions

But newer Codex expects a Responses API-style provider when wire_api = "responses" is used. So Codex appended /responses to a base URL that already ended in /chat/completions.

That produced:

/plan/v3/chat/completions/responses

At that point, rotating the API key is unlikely to help. The request is already going to the wrong protocol path.

Why not switch Codex back to Chat Completions?

That was the next thing I checked.

The newer Codex configuration rejects wire_api = "chat":

invalid configuration: `wire_api = "chat"` is no longer supported.
How to fix: set `wire_api = "responses"` in your provider config.

So this is not just a missing slash or a bad base URL. It is a protocol mismatch:

Codex wants to speak Responses API.
The LKEAP endpoint I was using speaks Chat Completions.
"OpenAI-compatible" does not automatically mean "compatible with every OpenAI client mode."

That last point is the real lesson.

My debugging order now

For this class of issue, I would check things in this order:

Inspect the final request URL.
Confirm the client's wire protocol.
Confirm the upstream endpoint shape.
Only then spend time on keys and permissions.

If the URL contains patterns like these, stop and look at path composition first:

/chat/completions/responses
/v1/v1
/responses/chat/completions

The status code may be a symptom. The URL shape is often the evidence.

Workaround: local protocol adapter

The workaround I tested toward was a small local Node.js proxy.

Codex calls a local Responses-shaped endpoint:

http://127.0.0.1:15722/v1/responses

The local proxy converts that into a Chat Completions request and forwards it to:

https://api.lkeap.cloud.tencent.com/plan/v3/chat/completions

The Codex config then points to the local proxy:

model_provider = "tencent_lkeap_proxy"
model = "glm-5.1"
disable_response_storage = true

[model_providers.tencent_lkeap_proxy]
name = "Tencent LKEAP via local Responses proxy"
wire_api = "responses"
base_url = "http://127.0.0.1:15722/v1"
requires_openai_auth = true
env_key = "OPENAI_API_KEY"

The real Tencent key stays in the proxy process environment:

$env:TENCENT_LKEAP_API_KEY="REDACTED"
$env:TENCENT_LKEAP_MODEL="glm-5.1"
node tools\codex-responses-to-chat-proxy.mjs

Codex still expects an OpenAI auth variable for this provider shape, so I used a local dummy value:

$env:OPENAI_API_KEY="local-proxy-dummy"

The proxy ignores that dummy value and uses TENCENT_LKEAP_API_KEY upstream.

Boundary

I would not describe this as a complete drop-in replacement.

What was verified in the original debugging record:

the failure path was identified
the local proxy script was created
node --check passed

Still to verify:

full end-to-end smoke test with a real LKEAP key
streaming behavior under longer tasks
Codex tool-call traffic
cancellation, timeout, and error mapping

That distinction matters. A protocol adapter can be useful, but it should be treated as an adapter to harden, not as magic compatibility.

The practical takeaway:

When an AI coding tool fails against an "OpenAI-compatible" endpoint, do not ask only whether the key is valid. Ask whether the client and server are actually speaking the same API shape.

Original version:
https://kunpeng-ai.com/en/blog/codex-lkeap-protocol-path-debugging/

Can Claude Code Still Use DeepSeek? A Windows Test with cc-switch

member_0af6418a — Fri, 15 May 2026 13:35:06 +0000

A lot of older third-party Claude model routes have become unreliable. I tested a narrower path on Windows: Claude Code through cc-switch to DeepSeek.

Important boundary first: cc-switch is not a Claude jailbreak, and it is not a universal adapter for every coding agent. It mainly helps with the Claude Code provider route. Codex cannot use this path directly.

What cc-switch actually solves

It reduces manual config drift.

Instead of hand-editing model name, base URL, and API key every time, you keep them as named providers and switch between them.

The package I used:

npm install -g @adithya-13/cc-switch

Windows traps

Two details mattered in my test.

First, PowerShell may block the npm-generated .ps1 shim. When that happens, try:

cmd /c cc-switch

Second, do not save the provider JSON config with a BOM. I hit a JSON parsing failure that disappeared after saving the config as UTF-8 without BOM.

Verification

I would not call the route ready until:

Active: DeepSeek

is visible, and the doctor check passes.

Only then did I restart Claude Code and test a small task.

Takeaway

This path is useful if you already use Claude Code and want a cleaner DeepSeek provider setup on Windows.

It is not a general solution for every agent. The practical value is narrower: make the provider state visible, avoid hand-edited config drift, and keep Windows shell/encoding issues from masquerading as model failures.

Windows agents keep freezing: lessons from an OpenClaw merge and a Hermes maintainer reply

member_0af6418a — Wed, 13 May 2026 14:11:49 +0000

Windows is a hard place to run long-lived AI coding agents.

The failure mode is often quiet. A terminal window may still be open. A process may still exist. But halfway through a task, the gateway stops responding, memory search breaks, or a background service silently exits.

This post summarizes two concrete trails from recent work:

OpenClaw merged a fix for a transient Windows file-lock problem in memory index swaps.
Hermes did not merge our Windows gateway helper PR, but a maintainer clarified how this work fits into a broader Windows support plan.

OpenClaw: transient file locks during memory index swaps

PR:

https://github.com/openclaw/openclaw/pull/76024

During memory reindexing, OpenClaw swaps SQLite index files. On Windows, fs.rename can fail when a file is briefly held by the system, antivirus software, an indexer, or another process.

The errors can look like:

EBUSY
EPERM
EACCES

From the user side, the symptom may be vague: memory search fails, or an agent task gets stuck.

The merged fix is intentionally narrow. It adds bounded retries around the atomic index swap path. It does not rewrite the memory system or turn every failure into a retry.

That is the kind of stability work that tends to matter in real agent use.

Cleanup paths matter too

Related OpenClaw trail:

https://github.com/openclaw/openclaw/pull/59137

This was not our original PR. We contributed a focused follow-up around cleanup ordering: close the temporary database before trying to remove temporary SQLite files.

On Windows, that detail matters. If the file handle is still open, the cleanup path can fail even if the main logic is correct.

Hermes: gateway lifecycle on Windows

PR:

https://github.com/NousResearch/hermes-agent/pull/15846

The Hermes proposal focused on a safer Windows gateway lifecycle:

start through a user-level Scheduled Task;
avoid relying on a visible PowerShell or CMD window;
track runtime state;
keep logs;
provide best-effort restart behavior.

The PR was closed and not merged.

The maintainer response was still useful: Hermes needs a consolidated Windows design rather than a set of piecemeal native-Windows PRs. The work was catalogued into the internal Windows support plan and may inform a later consolidated PR.

The lesson: do not trust the window

A visible terminal window is not a health check.

For Windows agents, the boring pieces matter:

background startup;
health checks;
logs;
bounded retries;
rollback paths;
small upgrade tests before using a new version for real work.

AI-agent demos usually focus on model behavior. Real usage eventually runs into process lifecycle, file locks, environment inheritance, and recovery.

Those are not side issues. They decide whether the agent can keep working.

The canonical version with the image cards and evidence trail is here:

https://kunpeng-ai.com/en/blog/openclaw-hermes-windows-agent-stability-evidence-trail/

DeepSeek TUI on Windows: A Practical Look at a Terminal-Native Coding Agent

member_0af6418a — Mon, 11 May 2026 03:35:30 +0000

DeepSeek TUI is an open-source terminal-native coding agent for DeepSeek models.

Project:

https://github.com/Hmbown/DeepSeek-TUI

At first glance, it is tempting to describe it as "DeepSeek's Claude Code-like tool." That comparison is useful, but only up to a point.

The more interesting point is this: DeepSeek TUI is not just a terminal chat interface. It is trying to bring the model closer to the actual engineering workspace, where files, shell commands, Git diffs, diagnostics, tool calls, and recovery workflows all matter.

I tested it on Windows and ran into one practical issue: the tool installed correctly, but the traditional PowerShell window flickered when launching the TUI. Switching to Windows Terminal fixed the problem.

The Short Version

DeepSeek TUI is worth watching because it combines several capabilities that a serious coding agent needs:

file reading, search, and editing;
shell command execution;
Git context and diffs;
MCP integration;
LSP diagnostics;
session resume;
workspace snapshots and rollback;
sub-agent workflows;
token, cache, and cost visibility.

That makes it closer to an engineering tool than a simple Q&A interface.

The Windows caveat is also straightforward: if the TUI flickers or fails to render correctly in a legacy console, try Windows Terminal before assuming the install or API key is broken.

What DeepSeek TUI Is

The official quickstart is:

npm install -g deepseek-tui
deepseek --version
deepseek --model auto

On first launch, DeepSeek TUI prompts for a DeepSeek API key. You can also configure it ahead of time:

deepseek auth set --provider deepseek
deepseek auth status

The project also documents other installation paths, including Scoop on Windows, Cargo, GitHub releases, and Docker images.

My Windows Test: Installed, Then Flickered

The installation itself was uneventful:

Install the package globally.
Run deepseek.
Configure the API key.
Launch the TUI again.

The problem appeared after that. In the traditional PowerShell window, the interface kept flickering and did not enter a stable usable state.

This is the kind of issue that is easy to misdiagnose. The first instinct is to reinstall the package, rotate the API key, or assume the npm package is broken.

In this case, the more likely cause was terminal rendering compatibility.

Modern TUI tools depend on terminal behavior such as ANSI control sequences, cursor refresh, keyboard events, pane rendering, clipboard handling, and sometimes mouse interaction. Legacy console environments can be less reliable here than Windows Terminal.

After switching to Windows Terminal, DeepSeek TUI launched normally.

Why This Category Matters

It moves the model into the workspace

In a web chat workflow, the model is far away from the project.

You copy code into the chat. You paste errors back. You run commands manually. You summarize diffs. You decide which files matter.

A terminal-native coding agent changes that boundary. It can inspect the workspace, read files, run commands, review diffs, and continue from real project state.

Code generation is not enough

A coding agent should not only write code. It should help answer operational engineering questions:

Which files are involved?
What changed?
Did tests or checks run?
What does the Git diff show?
Can the workspace be recovered if the change is wrong?
Are diagnostics fed back into the next repair step?

DeepSeek TUI's file operations, shell tools, Git context, session recovery, workspace snapshots, and LSP diagnostics all point in that direction.

MCP expands the tool boundary

DeepSeek TUI supports MCP. Its documentation describes both directions: it can load MCP servers from ~/.deepseek/mcp.json, and it can also run as an MCP server.

That matters because real engineering work is not limited to local files. Teams often need databases, browsers, internal docs, issue trackers, deployment systems, or private utilities.

LSP diagnostics help close the loop

Generating code is only the first step.

A developer still needs type errors, lint results, compiler output, and test failures to flow back into the next edit.

DeepSeek TUI's LSP diagnostic support is important because it helps the agent enter a repair loop: edit, inspect diagnostics, fix, and verify again.

Practical Windows Recommendations

If you are testing DeepSeek TUI on Windows, I would start with this sequence:

Install Node.js.
Install Windows Terminal.
Run npm install -g deepseek-tui inside Windows Terminal.
Check the install with deepseek --version.
Launch with deepseek --model auto.
Configure the API key when prompted.
If the interface flickers, switch terminals before reinstalling.
Start in a disposable test project.
Review Git diff and command output after each task.

Final Take

DeepSeek TUI is not just a chat wrapper. It is an open-source attempt to make DeepSeek useful inside a terminal-native engineering workflow.

Its combination of files, shell, Git, MCP, LSP diagnostics, session recovery, snapshots, sub-agents, and operating modes gives it the shape of a real coding agent.

The project is still moving quickly, so the experience will vary by platform and terminal. My Windows issue was real, but not severe: Windows Terminal solved it.

For developers watching the open-source coding-agent space, DeepSeek TUI is worth testing.

Original version:

https://kunpeng-ai.com/en/blog/deepseek-tui-windows-terminal-coding-agent/

Project:

https://github.com/Hmbown/DeepSeek-TUI

Related workflow thinking:

https://github.com/kunpeng-ai-lab/agent-collaboration-sop