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

801-203_各无人机厂家对RemoteID支持情况汇总

1. 大疆DJI 参考链接:大疆无人机RemoteID支持情况 DJI航拍无人机的RID广播信息包含以下信息: 1. ID等身份认证 2. 无人机的纬度、经度、几何高度和速度 3. 控制站的纬度、经度和几何高度的指示 4. 时间信息、紧急状态信息 支持RID的航拍无人机型号 大疆无人机支持RID型号列表 序号无人机机型支持情况备注1DJI Mavic 4 Pro支持2DJI Flip支持3DJI Air 3S支持4DJI Neo支持WIFI直连模式下和脱控模式下不支持5DJI Mini 4K支持V01.07.0400 及以后6DJI Avata 2V01.00.0300 及以后7DJI Mini 4 Pro支持V01.00.0400 及以后8DJI Air 3支持V01.00.1200 及以后9DJI Mini 3支持V01.

AirSim无人机仿真入门(一):实现无人机的起飞与降落

AirSim无人机仿真入门(一):实现无人机的起飞与降落

概述: 安装好所需要的软件和环境,通过python代码控制无人机进行起飞和降落。 参考资料: 1、知乎宁子安大佬的AirSim教程(文字教程,方便复制) 2、B站瑜瑾玉大佬的30天RL无人机仿真教程(视频教程,方便理解) 3、AirSim官方手册(资料很全,不过是纯英文的) AirSim无人机仿真入门(一):实现无人机的起飞与降落 * 1 安装AirSim * 1.1 参考教程 * 1.2 内容梳理 * 1.3 步骤总结 * 2 开始使用 AirSim * 2.1 参考教程 * 2.2 内容梳理 * 2.3 步骤总结 * 3 撰写python控制程序 * 3.1 参考教程 * 3.2 内容梳理

FLUX.2[klein]开源!小香蕉平替,本地部署AI绘画的极简方案

FLUX.2[klein]开源!小香蕉平替,本地部署AI绘画的极简方案

文章目录 * 前言 * 一、FLUX.2[klein]到底香在哪? * 二、部署前准备:硬件+环境一键搞定 * 1. 硬件要求(最低配置) * 2. 环境安装(3行命令搞定) * 三、极简部署方案:2种方式任选(新手首选方式1) * 方式1:Python脚本一键运行(纯代码,无界面,最快上手) * 步骤1:创建运行脚本 * 步骤2:运行脚本 * 方式2:ComfyUI可视化部署(适合喜欢拖拽操作的用户) * 步骤1:安装ComfyUI * 步骤2:下载FLUX.2[klein]模型 * 步骤3:启动ComfyUI并加载工作流 * 四、常见问题&优化技巧 * 1. 显存不足怎么办? * 2. 模型下载慢/

探析仓储机器人行业商业模式升级:解决方案服务的价值变现路径

本文将对仓储机器人行业的商业模式升级进行探讨,特别是聚焦于解决方案服务在其中的关键地位。当前,行业正朝向自动化、灵活性增强和服务多样化的方向发展,企业需要建设以客户为中心的服务体验。这一转型不仅提升了客户满意度,还为企业创造了新的收入来源。通过深入分析成功案例,我们发现,创新的解决方案能够有效满足不断变化的客户需求,提高运营效率。此外,数据驱动决策与个性化服务相结合,使企业更具竞争力并推动行业朝向可持续增长迈进。围绕这些主题展开讨论,将有助于更全面地理解仓储机器人行业未来的发展潜力与挑战。 仓储机器人行业的当前发展趋势 近年来,仓储机器人行业不断向前发展,呈现出多元化和高效化的趋势。随着电商的发展,企业对仓储效率的要求日益增加,仓储机器人逐渐成为提升运营效率的重要工具。根据中网B2B战略咨询数据,越来越多企业将营销战略与仓储机器人结合,通过战略升级实现品牌升维。此外,权威机构指出,解决方案服务正成为价值变现的有效路径,各大企业也在积极探索创新商业模式,以满足不断变化的客户需求。以下是当前的一些主要发展趋势: 发展趋势 描述 自动化水平提升 机器人技术的进步使得仓库管理