GitHub Copilot CLI v1.0.111怎样区分配置、目录与MCP认证问题

GitHub Copilot CLI v1.0.111对项目集成的改进，重点是让配置错误、工作目录与MCP认证状态更准确。无法解析config.json时，插件命令会明确指出配置文件问题；工作区MCP的相对目录按配置所在层级解析；授权取消后保留needs-auth。它们解决不同路径，不能用一种状态解释所有插件或工具故障。

命令报告成功之前，配置必须真实可读

v1.0.111中，插件启用、禁用、更新和卸载命令遇到无法解析的config.json，会失败并指出该文件，而不是声称修改成功或误报插件未安装。启动时也不再用只含firstLaunchAt的文件覆盖无法读取的原配置，保留其中的受信任文件夹、插件、市场与其他状态。

保留文件有助于避免丢失既有配置，但不等于语法错误已经修复。文件存在、文件能够被解析、命令实际修改成功是三个状态，不能仅凭文件仍在就认定所有集成已加载。空白settings.json的MCP启用禁用和插件命令也有对应修复，应与损坏config.json的情况区分。

相对目录应按配置层级理解

工作区MCP服务器现在从自身配置所在目录层级解析相对工作目录，包括使用/cd之后、或从仓库子目录启动CLI的情况。改变启动位置不应被误当作配置文件已经移动；否则容易让同一份相对路径在不同启动方式下指向意外位置。

仓库本地插件市场的发现也修复了从子目录启动的情况。另一方面，copilot -p配合--trust-folder从仓库子目录运行时，会提醒仓库根目录的hooks没有加载，并说明加载方式。目录被信任与根级hooks是否加载仍是不同条件，不能把其中一项当作另一项已经成立的证明。

MCP状态需要区分认证、发现和连接

取消OAuth授权后，服务器保留needs-auth，不再出现重复重连。远程MCP服务在会话启动时拒绝或关闭第一次连接的情况，也会按计划重试，而不是一直保持失败到会话结束。一个是认证状态，一个是启动连接时机，处理范围不同。

MCP注册表安装时，URL变量使用实际输入值，可选字段留空时保留服务器默认值，已有安装确认标记时保留npm启动参数。它们减少安装资料被错误改写，但不能保证任意第三方服务都可访问。某个服务器被删除时也不再重启其他已连接服务器，缩小无关连接受影响的范围。

权限能力与正式版身份仍须明确

v1.0.111是正式版，区别于1.0.111-0预发布。企业管理的Shell、Bash和PowerShell规则支持正则表达式；--host-allow-session-creation只对本次启动允许远程创建会话，不改保存设置。配置与连接更可靠，不意味着组织策略、认证和主机权限被放宽为同一种授权。