OpenClaw + GitHub Copilot GPT-5.4 技术修复指南

OpenClaw + GitHub Copilot GPT-5.4 Technical Fix Guide

Date: 2026-03-07

Overview

This guide documents how to make github-copilot/gpt-5.4 work inside OpenClaw when the model already works in OpenCode but fails in OpenClaw.

The final solution requires both:

  1. a config fix in ~/.openclaw/openclaw.json
  2. a runtime patch in the installed OpenClaw bundle

This is necessary because the problem is not only model registration. It is also an OpenClaw transport-routing issue for GitHub Copilot Responses API traffic.

Symptoms

The following errors may appear during debugging:

Symptom 1: model rejected

github-copilot/gpt-5.4 ... not allowed 

Symptom 2: IDE auth header missing

HTTP 400: bad request: missing Editor-Version header for IDE auth 

Symptom 3: unsupported provider mode

No API provider registered for api: github-copilot 

Symptom 4: wrong endpoint

HTTP 400: model "gpt-5.4" is not accessible via the /chat/completions endpoint 

Symptom 5: gateway instability

gateway disconnected: closed | idle 

Root Cause Analysis

There are four distinct problems.

1. Model config and allowlist mismatch

OpenClaw could see the provider, but github-copilot/gpt-5.4 was not fully wired into the active model config path used by the agent defaults.

2. Missing GitHub Copilot IDE headers

GitHub Copilot requires IDE-style headers for auth. OpenClaw was sending requests through a generic OpenAI-compatible path, so required headers were not included.

Required headers:

User-Agent: GitHubCopilotChat/0.35.0 Editor-Version: vscode/1.107.0 Editor-Plugin-Version: copilot-chat/0.35.0 Copilot-Integration-Id: vscode-chat 

Without them, Copilot returns:

missing Editor-Version header for IDE auth 

3. GPT-5.4 is not a Chat Completions model

gpt-5.4 must use the Responses API, not /chat/completions.

So this is wrong for gpt-5.4:

"api":"openai-completions"

This is required instead:

"api":"openai-responses"

4. OpenClaw transport routing only handled openai, not github-copilot

Even after changing gpt-5.4 to openai-responses, OpenClaw still fell back to the generic stream path because its embedded runner only activated the Responses transport for provider openai.

That caused OpenClaw to keep hitting /chat/completions for GitHub Copilot GPT-5.4.

Files Involved

Config file

~/.openclaw/openclaw.json

Installed OpenClaw runtime bundle

/home/water/.nvm/versions/node/v22.22.0/lib/node_modules/openclaw/dist/reply-DhtejUNZ.js

Reapply script

~/.openclaw/workspace/ken-patchs/reapply-openclaw-copilot-gpt54-patches.mjs

Step 1: Fix the OpenClaw config

Update the GitHub Copilot provider block in ~/.openclaw/openclaw.json.

Provider-level requirements

Use:

"baseUrl":"https://api.individual.githubcopilot.com","api":"openai-completions"

Why keep provider API as openai-completions?

  • OpenClaw runtime expects the provider to stay on a supported generic adapter path
  • switching the entire provider to github-copilot caused runtime/provider registration failures

Model-level requirements for GPT-5.4

Set the gpt-5.4 model entry to:

{"id":"gpt-5.4","name":"GPT-5.4","api":"openai-responses","reasoning":true,"input":["text","image"],"cost":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0},"contextWindow":128000,"maxTokens":64000}

Agent model registration

Make sure this exists:

"agents":{"defaults":{"models":{"github-copilot/gpt-5.4":{}}}}

Step 2: Patch OpenClaw to inject Copilot IDE headers

OpenClaw needs to attach Copilot IDE headers before sending provider requests.

In /home/water/.nvm/versions/node/v22.22.0/lib/node_modules/openclaw/dist/reply-DhtejUNZ.js, add a wrapper like this near the other provider wrappers:

constGITHUB_COPILOT_IDE_HEADERS={"User-Agent":"GitHubCopilotChat/0.35.0","Editor-Version":"vscode/1.107.0","Editor-Plugin-Version":"copilot-chat/0.35.0","Copilot-Integration-Id":"vscode-chat"};functioncreateGitHubCopilotHeadersWrapper(baseStreamFn){const underlying = baseStreamFn ?? streamSimple;return(model, context, options)=>{returnunderlying(model, context,{...options,headers:{...GITHUB_COPILOT_IDE_HEADERS,...options?.headers }});};}

Then apply it inside the provider wrapper logic:

if(provider ==="github-copilot") agent.streamFn =createGitHubCopilotHeadersWrapper(agent.streamFn);

Step 3: Patch OpenClaw to route GitHub Copilot Responses correctly

Find the branch that decides which stream transport to use.

Original behavior:

}elseif(params.model.api ==="openai-responses"&& params.provider ==="openai"){

Replace it with:

}elseif(params.model.api ==="openai-responses"&&(params.provider ==="openai"|| params.provider ==="github-copilot")){

Why this matters:

  • before the patch, github-copilot never entered the Responses transport branch
  • OpenClaw fell back to streamSimple
  • streamSimple hit /chat/completions
  • GPT-5.4 rejected that endpoint

After this patch:

  • github-copilot + openai-responses uses the correct Responses transport
  • GPT-5.4 no longer falls back to Chat Completions

Step 4: Validate and restart

Validate config JSON

node-e"JSON.parse(require('fs').readFileSync('/home/water/.openclaw/openclaw.json','utf8')); console.log('OK')"

Validate patched bundle syntax

node--check"/home/water/.nvm/versions/node/v22.22.0/lib/node_modules/openclaw/dist/reply-DhtejUNZ.js"

Restart gateway

openclaw gateway restart 

Verification Procedure

  1. Set the model to github-copilot/gpt-5.4
  2. Send a simple prompt like hi
  3. Confirm the gateway stays connected
  4. Confirm none of these errors return:
missing Editor-Version header for IDE auth model "gpt-5.4" is not accessible via the /chat/completions endpoint No API provider registered for api: github-copilot 

Reapply After OpenClaw Updates

Because the runtime fix patches the installed OpenClaw bundle, upgrades or reinstalls may overwrite it.

Use the reapply script:

node ~/.openclaw/workspace/ken-patchs/reapply-openclaw-copilot-gpt54-patches.mjs openclaw gateway restart 

Design Notes

Why not switch the whole provider to api: "github-copilot"?

That looked tempting, but OpenClaw’s runtime path did not have a compatible registered streaming provider for that mode in this setup, which caused runtime/provider registration failures.

Why not keep GPT-5.4 on openai-completions?

Because GitHub Copilot GPT-5.4 is not accessible on /chat/completions. It must go through the Responses API.

Why did OpenCode work earlier?

OpenCode already handled the GitHub Copilot transport path correctly, including the required Copilot headers and the proper API mode, while OpenClaw needed both config and runtime fixes.

  • Keep this guide with the reapply script path documented nearby
  • After any OpenClaw upgrade, rerun the patch script
  • If OpenClaw changes its bundle file name, update the script path target accordingly
  • If GitHub Copilot changes required IDE header versions, update both the runtime patch and reapply script

Quick Recovery Commands

node ~/.openclaw/workspace/ken-patchs/reapply-openclaw-copilot-gpt54-patches.mjs openclaw gateway restart openclaw status 

Final State

With the config fix and runtime patches in place, github-copilot/gpt-5.4 works in OpenClaw and the gateway remains stable.

Read more

【Agent】那个搞远程的向日葵也出 AI 了?!不用买设备,不用复杂配置,还支持多平台

【Agent】那个搞远程的向日葵也出 AI 了?!不用买设备,不用复杂配置,还支持多平台

那个搞远程的向日葵也出 AI 了?!不用买设备,不用复杂配置,还支持多平台 * 写在最前面 * 比openclaw更简单的配置过程,没有特定环境的需求 * 真正实用的地方,是它更接近现实场景 * 多平台、可查看、可接手,才是它更适合大众的原因 * 结语 🌌你好!这里是 晓雨的笔记本在所有感兴趣的领域扩展知识,感谢你的陪伴与支持~👋 欢迎添加文末好友,不定期掉落福利资讯 写在最前面 版权声明:本文为原创,遵循 CC 4.0 BY-SA 协议。转载请注明出处。 最近一段时间,“AI 操作电脑”这件事越来越火。很多人第一次看到这类演示时,都会觉得有点神奇:原来 AI 不只是会聊天、会写文案,居然真的开始会“用电脑”了。 也正因为这样,很多人会下意识觉得,所有“AI 控电脑”

【AI大模型入门】02:豆包——字节出品,国内用户最顺手的AI助手

【AI大模型入门】02:豆包——字节出品,国内用户最顺手的AI助手

【AI大模型入门】02:豆包——字节出品,国内用户最顺手的AI助手 📖 阅读时长:约8分钟 🎯 适合人群:想找一个好用、免费、无障碍访问的AI工具的新手 💡 你将学到:豆包是什么、有哪些功能、和其他AI有什么区别、怎么快速上手 一、豆包是什么? 豆包(Doubao)是字节跳动(抖音、今日头条的母公司)推出的AI大模型产品,于2023年8月正式上线。 如果你用过抖音、今日头条,那你已经间接体验过字节AI技术的成果了。豆包就是字节把这些技术能力集中打包,做成了一个对话式AI助手。 字节跳动 AI 产品矩阵: ┌─────────────────────────────────┐ │ 豆包(对话助手) ←── 本篇主角 │ │ 即梦(图像/视频生成) │ │ 剪映AI(视频剪辑AI) │ │ 扣子(AI Agent搭建平台) │ └─────────────────────────────────┘ 二、为什么推荐新手先用豆包? 在所有AI产品里,我特别推荐国内新手从豆包开始,原因很简单: 优势说明✅

AI 自动化测试:接口测试全流程自动化的实现方法

AI 自动化测试:接口测试全流程自动化的实现方法

在 AI 技术飞速渗透各行各业的当下,我们早已告别 “谈 AI 色变” 的观望阶段,迈入 “用 AI 提效” 的实战时代 💡。无论是代码编写时的智能辅助 💻、数据处理中的自动化流程 📊,还是行业场景里的精准解决方案 ,AI 正以润物细无声的方式,重构着我们的工作逻辑与行业生态 🌱。曾几何时,我们需要花费数小时查阅文档 📚、反复调试代码 ⚙️,或是在海量数据中手动筛选关键信息 ,而如今,一个智能工具 🧰、一次模型调用 ⚡,就能将这些繁琐工作的效率提升数倍 📈。正是在这样的变革中,AI 相关技术与工具逐渐走进我们的工作场景,成为破解效率瓶颈、推动创新的关键力量 。今天,我想结合自身实战经验,带你深入探索 AI 技术如何打破传统工作壁垒 🧱,让 AI 真正从 “概念” 变为 “实用工具” ,为你的工作与行业发展注入新动能 ✨。 文章目录 * AI 自动化测试:接口测试全流程自动化的实现方法 🤖 * 为什么传统自动化测试“卡壳”

AI自动化测试(一)

文章目录 * 1. 背景 * 2. 相关资料 * 2.1 底层框架 * 1. Playwright (Web UI自动化核心引擎) * 2. Chrome-devtools (Chrome开发者工具) * 3. Midscene (AI驱动的UI自动化工具) * 4. stagehand (AI浏览器自动化SDK) * 5. skyvern (AI浏览器自动化工具) * 6. browser-use (AI驱动的浏览器自动化工具) * 2.2 各大厂商的应用 * 各大厂AI自动化测试实践与技术方案汇总 * 技术路线总结 * 3. 重难点 * 3.1、页面理解困难的重难点与优化方案 * (一)纯视觉方案的局限性 * (二)纯DOM方案的缺陷 * (三)DOM+视觉融合方案的挑战 * (四)优化实施方案 * 3.2、规划能力的重难点与优化方案 * (一)