官方的 Claude Code 桌面版只有 macOS / Windows ，Linux 只能用命令行。我自己用 Linux ，就做了个非官方桌面版，已开源。 思路很简单：不是重写客户端，而是用 Electron 套一个真实终端（ xterm.js + node-pty ），里面跑你本机装好的 claude CLI 。所以命令行有的功能它全有——slash 命令、MCP 、插件、hooks 、skill 、权限交互，一个不少，只是多了个窗口外壳。 做了这些： 多标签页会话，每个标签可在不同目录 可视化「恢复会话」选择器（鼠标点选历史会话，不用敲 claude --resume ） 12 种界面语言（含阿拉伯语 RTL ）、5 套配色主题 打包成 AppImage 和 .deb ，应用图标 + Dock 集成 技术栈 Electron + xterm.js + node-pty ，在 Ubuntu 24.04 (Wayland + GNOME) 上开发测试。踩的坑（ chrome-sandbox 、libfuse2 、原生 Wayland 剪贴板不同步）都写在 README 里了。 GitHub： https://github.com/ydxred/claude-desktop Release （ AppImage / deb ）： https://github.com/ydxred/claude-desktop/releases 纯个人项目、非官方，欢迎试用 / 提 issue 。
他显示这个错误代码（0x80070005），在每次更新快完成的时候，就弹“无法完成更新，正在撤销更改，请不要关闭你的计算机”。 然后我去官网下载这个”win11安装助手“ 最后跑完进度条，自动重启之后显示这个 这是windows诊断结果 请问一下各位大佬有什么方法可以解决。 6 个帖子 - 6 位参与者 阅读完整话题
windows上用codex沙盒用不了好难受一直失败打算装个linux系统再？windows和苹果新的电脑佬们都有什么必备的安装软件推荐吗，畅所欲言 9 个帖子 - 9 位参与者 阅读完整话题
环境：Windows 11 x64，Claude Code v2.1.170 众所周知claude系列模型并不是非常擅长写powershell，经常写错，而且有因为转义问题导致删库的风险。 但是之前claude code 在windows上默认调用的终端都是git bash而不是powershell，claude可以使用熟悉的bash语法，不会遇到这些问题。 然鹅，今天更新claude code到2.1.170后，发现它开始使用powershell作为终端，/config也找不到切回git bash 的选项。 有佬友知道怎么把claude code终端切回git bash吗？ 5 个帖子 - 5 位参与者 阅读完整话题
刷帖子看到 电脑中勒索病毒 ，看了下佬们的分析，可能的原因是windows远程被强行爆破，ai被投毒。 其中分析到，中转站、skill、mcp都可能被投毒。 然后想到自己现在cc、codex都是直接运行在本地工作环境，用的是各公益站(叠甲，真心感谢各位公益大佬)，skill虽然用的不多，但也用了一些。 关键是因为很讨厌运行一会就要去审批，所以直接用的–dangerously-skip-permissions裸奔。 现在回想起来 不禁惊出一身冷汗。 万一哪个环节出一点点问题，那就完球了。 今天赶紧采取了一点预防措施。 安装了VMware ，虚拟了一个windows 11 LTSC，然后把cc和codex迁移到了虚拟机了。宿主机共享了一个工作目录给虚拟机，虚拟机就专门用来跑cc和codex，运行完后宿主机再把成果从共享的工作目录拿出来用。 这样就算以后出问题，也是虚拟机出问题，最多影响共享目录，宿主机也没问题。 或者佬们有没有什么更优雅的方案推荐 1 个帖子 - 1 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 GitHub - Hittopu/okfa-one-keyboard-for-all: okfa - one keyboard for all · GitHub 可以实现mac/windows的键盘一键切换成另外一台windows的键盘，可以实现在工位偶尔在另一台电脑上输入nvidia-smi的方便操作，也间接的实现了(mac键盘打瓦) 1 个帖子 - 1 位参与者 阅读完整话题
每次改完都要恢复一遍中文注释，很烦。有佬有办法吗 2 个帖子 - 2 位参与者 阅读完整话题
挺长时间了，CC只要外接中转，再开AutoMode就会报“Error: claude-opus-4-x is temporarily unavailable, so auto mode cannot determine the safety of Bash right now. ”一直没找到原因。 前几天看了哈雷佬的帖子 又来修一下CC 又来修一下CC 解锁 AutoMode 在不认可的LLM上的 门禁 （比如 Opus 4.6） 然而发现 4.8 也特么不工作啊 他就是一个 单独的LLM请求 提示词不一样 但不知道为什么这个分类器请求打过去 提示429 速率限制 又发现haiku是正常工作的 不得已我为了在Opus4.6上用 AutoMode 开出了个新变量 CLAUDE_CLASSIFIER_MODEL 可以设 分类器模型 佬给出了修补@cometix/claude-code的sh，翻了下站上还没有人分享Windows下的修补补丁 就照猫画虎糊了个py补丁 只要执行python apply-claude-code-patch-win.py就行，会自动找到安装的claude.exe在原地打补丁并自动创建一份带时间戳的备份。 记得通过CLAUDE_CLASSIFIER_MODEL指定分类器 发现上传不了附件，用百度网盘吧： 链接: 百度网盘 请输入提取码 提取码: r8g9 1 个帖子 - 1 位参与者 阅读完整话题
微软近日低调更新文档称，只要设备搭载满足条件的独立显卡，即便不是 Copilot+ PC，也可以在 Windows 11 上运行本地语言模型 API，这被视为削弱 Copilot+ PC 独占优势的重要一步。 根据最新说明，符合条件的硬件包括 NVIDIA GeForce RTX 30 系列及更新型号，并且显存需达到 6GB 及以上。 这意味着，一部分原本不符合 Copilot+ PC 标准的高性能 PC，将能够通过 GPU 获得系统级本地 AI 能力，而不再完全依赖具备高算力 NPU 的新机型。 Copilot+ PC 于 2024 年 6 月 18 日正式亮相，微软当时将其包装为运行本地 AI 的“唯一途径”，并以此作为推动 PC 更新换代的重要卖点。 按微软最初的定义，一台设备要被标记为 Copilot+ PC，至少需要配备 16GB 内存、固态硬盘，以及可提供不低于 40 TOPS 算力的 NPU（神经处理单元）。 NPU 被设计用于高效运行 AI 模型，强调能效比，而 GPU 则擅长大规模并行计算，具备更强的原始算力。 不过在此前的策略下，微软将 Windows Recall、“Click to Do”等本地 AI 功能限定在搭载 NPU 的 Copilot+ PC 上，导致许多在硬件性能上同样强大的 GPU 电脑无法使用这些内建 AI 能力。 这一次的转向来自微软在 GitHub 上的一则更新说明，微软在文档中确认，语言模型 API 已经可以在非 Copilot+ PC 上通过 GPU 运行，只要满足两项条件：一是拥有 RTX 30 系列或更新型号显卡，二是显卡显存达到至少 6GB。 微软在说明中称，“语言模型 API 现已可在搭载受支持 GPU 的非 Copilot+ PC 上运行，将本地语言模型能力带到更广泛的 Windows 11 设备。”受支持的硬件目前包括 NVIDIA GeForce RTX 30 系列及更新产品线，且显存须为 6GB 及以上。 在实质效果上，这一调整将本地语言模型的适用范围从新款 Copilot+ PC 拓展到大量已在使用中的高性能 Windows 11 设备。 从开发者视角来看，语言模型 API 提供了一套可以在本地调用的 Windows.AI.Text 接口，背后由名为 “Phi Silica” 的小型语言模型提供支持。 该模型此前已在 Microsoft Edge 等产品中出现，用于“Rewrite using AI”（使用 AI 改写）等功能。 按照微软的设定，目前普通 Windows PC 默认并不预装本地 AI 模型，只有购买 Copilot+ PC 的用户才会在系统中预置相关内容。 在新方案下，如果用户运行支持本地语言模型 API 的应用，系统可以通过 Windows Update 下载 Phi Silica 模型，并在满足条件的 GPU 上本地运行。 基于目前公布的接口能力，开发者可以在应用中调用的本地 AI 功能包括：利用 Windows.AI.Text 接口实现的文本智能格式化，文本摘要（TextSummarizer），改写（TextRewriter），文本转表格（TextToTableConverter），以及通用的提示词生成等。 换言之，只要硬件达标，用户将能够在 Windows 应用中原生获得类似 ChatGPT 的部分文本处理体验，而且计算过程完全在本地完成，相比依赖云端模型的 Copilot 或 ChatGPT，在隐私保护方面更具优势。 需要注意的是，微软目前仅在语言模型 API 这一层面放开了 GPU 的适用范围。 就现有信息来看，Windows Recall、“Click to Do”以及画图（MS Paint）等应用中的部分 AI 功能，仍暂时只对内置 NPU 的 Copilot+ PC 开放。 换句话说，此次调整更多是为文字与提示类本地 AI 能力“解锁”更广泛的硬件平台，而非全面取消 NPU 在 Copilot+ 生态中的门槛。 尽管如此，随着本地 AI 能力逐步向传统高性能 GPU PC 延伸，Copilot+ PC 作为“唯一能本地运行 AI”的卖点已经明显被削弱，这也让外界开始猜测，微软未来是否会进一步放宽甚至取消对 NPU 的强制要求。 查看评论
一般还要看哪里配置区别呢？ 最近新订了一个机场，协议上只支持 verge 的，我就安装了这个了，旧的 clash for windows 没有卸载。 然后新机场感觉一般，就切换之前常用的了，两个客户端都支持，网页啥的都正常扶墙。 然后网页浏览 github 也正常的 但是推代码的时候，verge 就是不成功， ``` unable to access failed to connect to github.com xxx time out 。 ``` 有人知道啥原因吗？ 我也没有对 verge 做特殊的配置。
一般还要看哪里配置区别呢？ 最近新订了一个机场，协议上只支持 verge 的，我就安装了这个了，旧的 clash for windows 没有卸载。 然后新机场感觉一般，就切换之前常用的了，两个客户端都支持，网页啥的都正常扶墙。 然后网页浏览 github 也正常的 但是推代码的时候，verge 就是不成功， ``` unable to access failed to connect to github.com xxx time out 。 ``` 有人知道啥原因吗？ 我也没有对 verge 做特殊的配置。
一般还要看哪里配置区别呢？ 最近新订了一个机场，协议上只支持 verge 的，我就安装了这个了，旧的 clash for windows 没有卸载。 然后新机场感觉一般，就切换之前常用的了，两个客户端都支持，网页啥的都正常扶墙。 然后网页浏览 github 也正常的 但是推代码的时候，verge 就是不成功， ``` unable to access failed to connect to github.com xxx time out 。 ``` 有人知道啥原因吗？ 我也没有对 verge 做特殊的配置。
一直用 windows 本，家的笔记本配置普通。 产生买 mini 的想法是自己剪辑的话 不是很够用； 因为我一般把素材放到 nas 里 然后通过 smb 来进行剪辑 或者是通过外接的 ssd 硬盘来剪辑。 这两种方式 传输速度上都没问题的 nas 也在 250/s 以上。 我的 windows 本 每次素材导入进去 直接剪辑的话 会很卡，只能生成代理，生成代理的时间又很久，很耽误时间。 如果我换一个 mac mini 哪个配置的能解决上述问题?
一直用 windows 本，家的笔记本配置普通。 产生买 mini 的想法是自己剪辑的话 不是很够用； 因为我一般把素材放到 nas 里 然后通过 smb 来进行剪辑 或者是通过外接的 ssd 硬盘来剪辑。 这两种方式 传输速度上都没问题的 nas 也在 250/s 以上。 我的 windows 本 每次素材导入进去 直接剪辑的话 会很卡，只能生成代理，生成代理的时间又很久，很耽误时间。 如果我换一个 mac mini 哪个配置的能解决上述问题?
要windows电脑可用的，那种最好是悬浮在电脑上，随时可以查看今天的任务，完成的情况，佬友有没有推荐的软件 1 个帖子 - 1 位参与者 阅读完整话题
1.用管理员身份打开 Windows PowerShell 输入代码，等待加载完成 Invoke-WebRequest "http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/f90c8266-7651-4aa0-a508-79555e3b74e5?P1=1781155129&P2=404&P3=2&P4=aEC7AAs4D%2bUWbPfXGqCJuUcFfbK3QWpC3qi3qpL25FQXKiqNEm061AkeQGjnTv5Wshfp1JZLnKsaJ1Y%2bFT55zA%3d%3d" -OutFile codex.msix 2.加载完成后回车再输入 Add-AppxPackage codex.msix 加载完成 就安装成功codex，直接本地搜 codex 就能出现 1 个帖子 - 1 位参与者 阅读完整话题
公司领导要求调研国产计算卡算力生态，要求如下： 1、windows/linux通用，像普通显卡一样插pcie 2、开发api最好类cuda/cudnn，不像也没关系 3、推理性能>=RTX 3060，只能高不能低 有玩过类似计算卡的佬能给点意见吗，这个要求国产卡能不能达到 1 个帖子 - 1 位参与者 阅读完整话题
GitHub Copilot有次数限制，windsurf感觉一般般，supermaven用起来倒是蛮不错，速度很快，但想知道还有没有其他更好用的。 1 个帖子 - 1 位参与者 阅读完整话题
💡 背景 一直在 WSL2 里面使用 codex-cli ，近期看到 Windows 端 App 支持联动手机 App 并能控制电脑，便打算安装体验一下。 代理软件使用 Clash 。 由于 Clash 的 TUN 模式 对 WSL2 的网络影响非常大，因此不考虑开启 TUN 模式。 不希望开启全局的 系统代理（ System Proxy ） 模式。 最终选择使用 Proxifier 进行进程级的代理接管。 ❌ 踩坑过程与问题现象 尝试方案 1：Proxifier 常规配置（失败） 在 Proxifier 中添加好本地代理服务器后，配置了一条常规规则：将 codex 和 Codex.exe 加入 Target Applications 列表，Action 设为 强制走代理（ Proxy ） 。 现象： Codex 界面可以打开，但个人资料无法读取、额度用量查看不了、模型问答一直卡在 thinking 状态。查看 Proxifier 日志未发现明显异常。 尝试方案 2：使用 .env 配置文件（失败） 关掉 Proxifier ，尝试在 Codex 目录中添加 .env 配置文件并写入代理环境变量（如 HTTP_PROXY / HTTPS_PROXY ）。 现象： Codex 打开速度极其缓慢，随后依然无法查看用量、个人资料，且 完全无法连接手机 APP 。 痛点： 坚决不想用系统代理，同时由于 WSL2 的存在，也无法使用 TUN 模式，一时间陷入僵局。 🔍 转机与排查思路 网上关于这个客户端类似问题的资料极少，各类 AI （ Gemini 、ChatGPT 、豆包等）给出的方案也大多是陈词滥调（比如盲目让你添加一堆别的无关进程规则），根本解决不了问题。 随后换了个提问思路： “为什么添加了 .env 代理后，部分本地服务反而无法正常打开？” AI 提示了一个关键点： Codex 的部分服务（如 UI 与后端核心进程的通信、手机 App 的本地配对等）会走本地回环（ Localhost ）。如果一股脑全把流量送去代理服务器，会导致本地通信死循环或被代理软件拦截。 这也是为什么别的帖子让人加一堆乱七八糟的进程规则都踩坑的原因——方向错了。 ✅ 解决方案 既然知道了症结在于“本地回传流量被误代理”，解决办法就很简单了。在 Proxifier 中为 Codex 单独做一下流量分流， 将本地回环（ Localhost ）强制直连 。 Proxifier 规则配置步骤： 保留 原本让 codex / Codex.exe 走代理的规则。 新增 一条排在最前方的优先级规则（ 确保这条规则在代理规则之上 ）： Applications: codex; Codex.exe Targets (目标地址): localhost; 127.0.0.1 Action: Direct (直连) 📌 核心逻辑： 必须确保目标是本地（ Localhost ）的流量强制走 Direct （直连），其余的外网请求再走 Proxy （代理）。 🎉 结果验证 保存规则并重新打开 Codex ，一切恢复正常： 界面秒开，展现速度极大提升。 个人资料、额度用量读取完全正常。 手机 APP 连接与电脑操控一切正常！ 总结： 遇到类似独立客户端网络异常时，除了盯着外网规则，不妨看一眼是不是本地回环（ Localhost ）被代理误伤了。希望这个思路能帮到遇到类似困境的朋友，少走弯路！
如题，昨天开始 就很卡 新建一个聊天 发一个信息 要看着发送符号要转圈 才能发出去 然后模型开始要思考很久就一个简单的 查询今天天气 要三分钟才能处理完 这是API站点的问题吗？ 但是换了几个公益站 都感觉很卡 要思考很久 6 个帖子 - 3 位参与者 阅读完整话题