Ubuntu 22.04 下 VS Code Codex 插件一直卡在加载页的完整排查与解决方法

asciiliu

376人浏览 · 2026-07-19 11:58:10

asciiliu · 2026-07-19 11:58:10 发布

文章摘要：

记录 Ubuntu 22.04 中 VS Code Codex 插件在本地与 Remote-SSH 窗口随机卡在加载页的问题。通过对比终端和侧边栏启动方式、检查 Linux 文件描述符软硬限制及 VS Code 子进程继承关系，最终将问题定位为图形桌面启动时部分进程的 soft nofile 为 1024，并通过高限制启动脚本和用户级 desktop 文件完成修复。

分类建议：

开发环境与故障排查

封面建议：

可以截取以下内容制作封面：

VS Code Codex 一直加载
soft nofile：1024
终端启动正常，侧边栏启动失败

# Ubuntu 22.04 下 VS Code Codex 插件一直卡在加载页的完整排查与解决方法

## 一、问题背景

我的开发环境如下：

- 操作系统：Ubuntu 22.04
- 编辑器：Visual Studio Code
- 使用方式：
  - 本地直接打开 VS Code
  - 通过 VS Code Remote-SSH 连接服务器
- 插件：OpenAI Codex
- 当时使用的 VS Code 版本：`1.128.1`
- 当时使用的 Codex 扩展目录：

```text
~/.vscode/extensions/openai.chatgpt-26.5715.31925-linux-x64

一开始，我是在 Remote-SSH 窗口中发现问题的，因此首先怀疑的是：

Remote-SSH 连接异常；
远程服务器上的 .vscode-server 损坏；
Codex 后台进程无法在服务器启动；
SSH 配置或者网络代理存在问题。

但是经过进一步测试，我发现：

即使完全不连接远程服务器，只在本地打开 VS Code，Codex 也会随机卡在加载页面。

因此，这个问题不能简单归因于 SSH 或远程服务器。

二、具体故障现象

问题主要表现为：

打开 VS Code；
点击左侧活动栏中的 Codex 图标；
Codex 页面一直显示加载动画；
没有明确的报错弹窗；
第一个 VS Code 窗口有时能正常打开；
第二个或第三个窗口更容易打不开；
有时所有窗口都正常，有时只有部分窗口正常；
本地窗口和 Remote-SSH 窗口都可能出现；
删除下面的目录后，第一次打开通常能恢复：

~/.config/Code/Service Worker

但是在继续打开新窗口、重新启动 VS Code，或者再次进入 Codex 后，问题又会复现。

整个现象看起来非常随机，像是在“碰运气”。

三、为什么删除 Service Worker 只能暂时恢复

VS Code 中的 Codex 面板并不是一个普通的原生控件，而是一个 Webview。

可以把 Webview 简单理解为：

VS Code 内部嵌入的一个网页运行环境。

Codex 页面打开时，需要加载很多资源，包括：

JavaScript 文件；
CSS 样式文件；
字体和图标；
Webview 本地资源；
Service Worker；
Codex 后台服务通信；
本地 IPC Socket；
网络连接；
日志和缓存文件。

~/.config/Code/Service Worker 中保存了部分 Webview 缓存和运行状态。

将其删除后，相当于让 VS Code 重新建立 Webview 缓存，因此第一次可能恢复正常。

但需要注意：

删除 Service Worker 只清除了缓存，并没有修改 Linux 对 VS Code 进程的资源限制。

如果真正的问题是某些 VS Code 进程能够打开的资源数量太少，那么缓存重建后，随着窗口和插件资源继续增加，问题仍然会出现。

所以，删除 Service Worker 更像是暂时清理了故障状态，而不是解决了根因。

四、第一步排查：确认 VS Code 是否真正退出

最开始，我使用下面的命令检查 VS Code 进程：

pgrep -a -f 'code|Code'

但是输出中除了 VS Code，还出现了 Obsidian 和 QQ，例如：

--code-cache-schemes=app

这是因为正则中的 code 也会匹配其他 Electron 程序参数里的：

code-cache-schemes

因此，这条命令会产生误报。

更准确的检查方法是：

pgrep -a -f '^/usr/share/code/code'

或者：

ps -eo pid,comm,args \
  | grep -E '[C]ode|[/]code' \
  | grep -vE 'obsidian|QQ|code-cache'

在关闭全部 VS Code 窗口后，可以执行：

pgrep -a -f '^/usr/share/code/code' \
  || echo "VS Code 已完全退出"

如果仍然能看到 /usr/share/code/code 进程，说明 VS Code 并没有真正退出。

这一步非常重要，因为 VS Code 通常会复用已经存在的主进程。

即使在新终端中执行：

ulimit -Sn 65536
code --new-window

只要之前的低限制 VS Code 主进程仍然运行，新窗口仍可能由旧主进程创建。

此时，新终端中的 ulimit 设置不会真正应用到旧进程。

五、关键线索：Linux 文件描述符限制

执行下面的命令：

printf 'soft nofile: '; ulimit -Sn
printf 'hard nofile: '; ulimit -Hn

得到结果：

soft nofile: 1024
hard nofile: 1048576

这是本次问题中最关键的线索。

5.1 什么是文件描述符

Linux 中，程序访问某个系统资源时，通常会获得一个编号，这个编号叫做：

文件描述符
File Descriptor
FD

虽然名字中包含“文件”，但文件描述符不仅代表普通文件，还包括：

打开的代码文件；
JavaScript、CSS、图片和字体；
网络连接；
本地 Socket；
进程通信管道；
Remote-SSH 通道；
日志文件；
Webview 资源；
插件后台进程通信。

可以将文件描述符理解为：

程序访问系统资源时需要使用的“资源通行证”。

每打开一个文件、建立一个网络连接，或者创建一条进程通信通道，都可能占用一个文件描述符。

5.2 soft nofile 和 hard nofile 的区别

我的系统显示：

soft nofile: 1024
hard nofile: 1048576

其中：

soft nofile：当前进程默认实际执行的限制；
hard nofile：普通用户能够将软限制提高到的最大值。

可以类比为：

系统仓库最多可以容纳 1,048,576 件物品，但默认只给当前程序开放了 1,024 个货位。

当某个相关进程需要打开第 1025 个资源时，系统就可能拒绝它。

对于简单命令行程序，1024 通常足够。

但 VS Code 是一个复杂的 Electron 应用，其中包含：

VS Code 主进程
├── Renderer 渲染进程
├── Zygote 进程
├── GPU 进程
├── Network Service
├── Extension Host
├── Remote-SSH
├── Codex 后台服务
└── Codex Webview

当同时打开多个窗口、多个插件、Remote-SSH 和 Codex Webview 时，1024 可能过低。

六、对照实验：临时提高限制后问题消失

首先确保全部 VS Code 进程完全退出。

然后在终端执行：

ulimit -Sn 65536
printf 'new soft nofile: '; ulimit -Sn

输出：

new soft nofile: 65536

接着必须在同一个终端中启动 VS Code：

code --new-window

测试结果为：

第一个 VS Code 窗口中的 Codex 正常；
第二个窗口中的 Codex 正常；
第三个窗口中的 Codex 也正常。

而此前从 Ubuntu 侧边栏直接打开时，第二个或第三个窗口经常加载失败。

这个对照实验说明：

提高 VS Code 启动环境中的文件描述符软限制后，Codex 多窗口加载问题可以稳定消失。

七、为什么有些进程是 1048576，有些仍然是 1024

为了查看 VS Code 实际进程的限制，可以执行：

for pid in $(pgrep -f '^/usr/share/code/code'); do
    printf 'PID %-8s ' "$pid"
    grep 'Max open files' "/proc/$pid/limits" 2>/dev/null
done

实际观察到了类似结果：

PID 857309   Max open files  1048576  1048576  files
PID 857313   Max open files  1024     1048576  files
PID 857314   Max open files  1024     1048576  files
PID 857349   Max open files  16384    1048576  files
PID 857351   Max open files  1048576  1048576  files

这说明不同 VS Code 子进程的限制并不完全相同。

某些进程可能在启动后主动提高自己的软限制，但某些：

zygote；
renderer；
utility；
extension host；

仍然可能继承图形桌面会话的默认值 1024。

因此：

不能只看到 VS Code 主进程是 1048576，就认为所有相关进程都没有限制问题。

真正应该关注的是参与 Codex Webview 资源加载的 Renderer、Utility 和扩展宿主进程。

只要其中的关键进程仍然是 1024，Codex 页面仍然可能加载失败。

八、最终定位：终端启动正常，侧边栏启动失败

进一步测试两种启动方式。

方式一：终端启动

ulimit -Sn 65536
code --new-window

结果：

Codex 正常

方式二：Ubuntu 侧边栏启动

直接点击 Ubuntu Dock 中的 VS Code 图标。

结果：

Codex 仍然卡在加载页面

这说明问题和 VS Code 的启动来源有关。

8.1 为什么终端和侧边栏启动不同

在终端执行：

ulimit -Sn 65536

只会影响：

当前 Shell；
以及从当前 Shell 启动的子进程。

因此，从这个终端启动的 VS Code 会继承 65536。

但是 Ubuntu 侧边栏中的应用由 GNOME 图形桌面启动。

它不是当前终端的子进程，也不会执行当前终端中的：

ulimit -Sn 65536

所以侧边栏启动的 VS Code 仍可能继承：

soft nofile = 1024

整个问题链条可以表示为：

终端启动 VS Code
    ↓
继承 soft nofile=65536
    ↓
Codex 正常

Ubuntu Dock 启动 VS Code
    ↓
部分子进程继承 soft nofile=1024
    ↓
Codex Webview 部分资源无法加载
    ↓
Codex 一直停留在加载页面

到这里，问题根因已经基本确定。

九、最终解决方案

最终采用的方案是：

创建一个专门的 VS Code 启动脚本；
在脚本中先执行 ulimit -Sn 65536；
再启动真正的 VS Code；
创建用户级 code.desktop 文件；
让 Ubuntu 侧边栏通过这个脚本启动 VS Code。

这个方案具有以下优点：

只影响 VS Code；
不需要修改全系统限制；
不影响其他应用；
普通 VS Code 更新后通常仍然有效；
不依赖 GNOME 是否读取 Shell 配置；
比只修改 .bashrc 更可靠。

十、创建高文件描述符启动脚本

执行：

mkdir -p ~/.local/bin

cat > ~/.local/bin/code-highfd <<'EOF'
#!/usr/bin/env bash

# 避免 VS Code 从图形桌面继承 soft nofile=1024
ulimit -Sn 65536

exec /usr/bin/code "$@"
EOF

chmod +x ~/.local/bin/code-highfd

测试脚本：

~/.local/bin/code-highfd --version

如果能够正常输出 VS Code 版本，说明启动脚本工作正常。

这里使用：

/usr/bin/code

而不是直接使用：

/usr/share/code/code

原因是 /usr/bin/code 通常是更加稳定的命令入口。

十一、创建用户级 VS Code 桌面入口

系统级 VS Code 桌面文件通常位于：

/usr/share/applications/code.desktop

将它复制到用户目录：

mkdir -p ~/.local/share/applications

cp /usr/share/applications/code.desktop \
   ~/.local/share/applications/code.desktop

然后将桌面文件中的启动命令替换为刚才创建的脚本：

sed -i \
  "s#^Exec=/usr/share/code/code#Exec=$HOME/.local/bin/code-highfd#" \
  ~/.local/share/applications/code.desktop

为了同时兼容 /usr/share/code/code 和 /usr/bin/code 两种写法，也可以直接使用：

sed -E \
  "s#^Exec=(/usr/share/code/code|/usr/bin/code)#Exec=$HOME/.local/bin/code-highfd#" \
  /usr/share/applications/code.desktop \
  > ~/.local/share/applications/code.desktop

刷新桌面应用数据库：

update-desktop-database ~/.local/share/applications \
  2>/dev/null || true

检查修改结果：

grep '^Exec=' ~/.local/share/applications/code.desktop

预期看到类似：

Exec=/home/用户名/.local/bin/code-highfd %F
Exec=/home/用户名/.local/bin/code-highfd --new-window %F

只要所有主要 Exec= 项已经指向：

~/.local/bin/code-highfd

就说明修改成功。

十二、完全退出旧的 VS Code 进程

修改 desktop 文件后，必须完全关闭旧的 VS Code。

否则，新窗口可能继续复用原来继承 1024 限制的主进程。

先保存全部文件，然后正常退出 VS Code。

检查是否还有进程：

pgrep -a -f '^/usr/share/code/code'

如果确认文件已经保存，但进程仍未退出，可以执行：

pkill -TERM -f '^/usr/share/code/code'
sleep 3

pgrep -a -f '^/usr/share/code/code' \
  || echo "VS Code 已完全退出"

检查 Codex 后台进程：

pgrep -a -f '/openai\.chatgpt-.*/codex'

如果存在明显残留，可以执行：

pkill -TERM -f '/openai\.chatgpt-.*/codex'

不建议一开始直接使用：

kill -9

优先使用 TERM，让程序有机会正常保存状态并释放资源。

十三、清理一次旧的 Webview 缓存

此前 Codex 已经多次在低文件描述符限制下加载失败，因此建议在 VS Code 完全退出后，备份并重建一次缓存。

执行：

timestamp="$(date +%Y%m%d_%H%M%S)"

for dir in \
  "$HOME/.config/Code/Service Worker" \
  "$HOME/.config/Code/Cache" \
  "$HOME/.config/Code/CachedData" \
  "$HOME/.config/Code/GPUCache"
do
    if [ -e "$dir" ]; then
        mv "$dir" "${dir}.bak.${timestamp}"
    fi
done

这里使用“改名备份”而不是直接删除。

不要删除以下目录：

~/.config/Code/User
~/.codex
~/.vscode
~/.vscode-server
~/.ssh

这些目录中可能包含：

VS Code 用户设置；
Codex 配置和登录状态；
本地插件；
Remote-SSH 服务端插件；
SSH 密钥和连接配置。

本次问题不需要通过删除这些目录解决。

十四、重新固定 Ubuntu 侧边栏图标

Ubuntu Dock 可能仍然缓存旧的系统级 desktop 文件。

建议执行以下操作：

右键侧边栏中的 VS Code；
选择“从收藏夹中移除”；
打开“显示应用程序”；
搜索 Visual Studio Code；
启动一次；
再将新图标固定到侧边栏。

也可以直接测试用户级 desktop 文件：

gio launch ~/.local/share/applications/code.desktop

如果通过 gio launch 启动后 Codex 正常，而从 Dock 启动仍然异常，说明 Dock 仍然缓存了旧入口。

此时可以注销当前用户后重新登录：

gnome-session-quit --logout

注销前务必保存当前工作。

十五、验证修复是否生效

从 Ubuntu 侧边栏重新打开 VS Code 后，执行：

for pid in $(pgrep -f '^/usr/share/code/code'); do
    cmd="$(tr '\0' ' ' < "/proc/$pid/cmdline" 2>/dev/null)"

    type="$(printf '%s' "$cmd" \
      | sed -n 's/.*--type=\([^ ]*\).*/\1/p')"

    [ -n "$type" ] || type="main-or-helper"

    soft="$(awk '/Max open files/{print $4}' \
      "/proc/$pid/limits" 2>/dev/null)"

    printf 'PID=%-8s soft=%-8s type=%s\n' \
      "$pid" "$soft" "$type"
done

重点观察：

type=renderer
type=utility
type=main-or-helper

理想结果为：

soft=65536

或者：

soft=1048576

两者都可以。

关键是参与 Codex Webview 加载的进程不应继续显示：

soft=1024

查看实际使用的文件描述符数量

可以执行：

for pid in $(pgrep -f '/usr/share/code/code --type=renderer'); do
    fd_count="$(
      find "/proc/$pid/fd" \
        -mindepth 1 \
        -maxdepth 1 \
        2>/dev/null \
      | wc -l
    )"

    printf 'Renderer PID=%-8s open_fd=%s\n' \
      "$pid" "$fd_count"
done

需要说明的是：

将上限设置为 65536，并不代表 VS Code 会立即占用 65536 个文件描述符。

这只是允许 VS Code 在需要时最多使用这么多。

实际使用数量通常远小于限制值。

十六、为什么不直接修改 `.bashrc`

有些教程建议在 ~/.bashrc 中加入：

ulimit -Sn 65536

这种方式只对以下情况有效：

打开 Bash 终端；
从该终端启动程序。

但是 Ubuntu Dock 启动的 VS Code 不是 Bash 的子进程，因此它通常不会读取交互式 .bashrc 中的 ulimit。

最终可能仍然出现：

终端启动：正常
侧边栏启动：失败

使用 code-highfd 启动脚本的优点是：

无论从终端还是桌面入口启动，都会先主动设置限制。

因此更稳定。

十七、为什么本地问题会影响 Remote-SSH

在 Remote-SSH 场景中，VS Code 可以简单分成两部分：

本地 Ubuntu
├── VS Code 主界面
├── Codex 侧边栏 Webview
├── Electron Renderer
└── Remote-SSH 客户端

远程服务器
├── ~/.vscode-server
├── 远程扩展宿主
└── 远程工作区进程

即使代码和终端运行在远程服务器上，Codex 面板仍然需要由本地 VS Code 进行渲染。

因此，本地 Renderer 或 Webview 存在资源限制时，会同时导致：

本地窗口中的 Codex 卡住；
Remote-SSH 窗口中的 Codex也卡住。

这也说明：

当本地和远程都出现相同加载问题时，不应该首先删除服务器端 .vscode-server。

如果 Remote-SSH 可以正常连接，远程文件和终端也能正常使用，那么 SSH 配置通常不是 Codex 加载失败的首要原因。

十八、什么时候需要检查服务器端

只有在本地高限制启动已经正常，但 Remote-SSH 窗口仍单独失败时，才继续检查服务器。

可以执行：

ls -ld ~/.vscode-server
ls -ld ~/.codex
ls -ld /tmp
ls -ld /tmp/codex-ipc 2>/dev/null

重点检查：

文件夹所有者是否正确；
是否被其他用户创建；
是否存在 Permission denied；
/tmp/codex-ipc 是否可写；
远程扩展宿主是否反复退出。

如果怀疑远程 VS Code Server，可以先在命令面板中执行：

Remote-SSH: Kill VS Code Server on Host...

不建议一开始就执行：

rm -rf ~/.vscode-server

因为这会同时删除：

远程 VS Code Server；
所有远程扩展；
扩展运行数据；
有价值的诊断日志。

十九、VS Code 更新后如何处理

本次修复使用的是：

~/.local/bin/code-highfd
~/.local/share/applications/code.desktop

这两个文件位于用户目录中。

正常使用以下命令更新 VS Code：

sudo apt update
sudo apt upgrade

一般不会删除这两个文件。

因此，普通更新后通常不需要重新配置。

不过，大版本更新后，系统级 desktop 文件可能增加新的启动参数。

可以重新同步一次：

mkdir -p ~/.local/share/applications

sed -E \
  "s#^Exec=(/usr/share/code/code|/usr/bin/code)#Exec=$HOME/.local/bin/code-highfd#" \
  /usr/share/applications/code.desktop \
  > ~/.local/share/applications/code.desktop

chmod 644 ~/.local/share/applications/code.desktop

update-desktop-database ~/.local/share/applications \
  2>/dev/null || true

更新后应完全退出旧版本 VS Code，再重新启动。

否则：

新窗口可能继续复用旧版本进程；
新 desktop 文件不会立即生效；
新的文件描述符限制也不会重新继承。

二十、Codex 插件更新后再次卡住怎么办

如果以后更新 Codex 插件后再次卡在加载页面，可以按照以下顺序处理。

第一步：查看进程限制

for pid in $(pgrep -f '^/usr/share/code/code'); do
    printf 'PID %-8s ' "$pid"
    grep 'Max open files' "/proc/$pid/limits" 2>/dev/null
done

第二步：完全退出 VS Code

pkill -TERM -f '^/usr/share/code/code'

第三步：备份清理 Webview 缓存

timestamp="$(date +%Y%m%d_%H%M%S)"

for dir in \
  "$HOME/.config/Code/Service Worker" \
  "$HOME/.config/Code/Cache" \
  "$HOME/.config/Code/CachedData" \
  "$HOME/.config/Code/GPUCache"
do
    if [ -e "$dir" ]; then
        mv "$dir" "${dir}.bak.${timestamp}"
    fi
done

第四步：从修复后的桌面入口启动

gio launch ~/.local/share/applications/code.desktop

不要直接删除：

~/.codex
~/.vscode
~/.vscode-server
~/.ssh

二十一、如何查看 Codex Webview 错误

当 Codex 卡在加载页面时，可以在 VS Code 中打开：

帮助 → 切换开发人员工具

在 Console 中搜索：

ERR_INSUFFICIENT_RESOURCES
net::ERR_FAILED
service worker
openai.chatgpt
codex
ERR_FILE_NOT_FOUND

还可以在终端中搜索最近日志：

find ~/.config/Code/logs \
  -type f \
  -mmin -10 \
  -print0 \
| xargs -0 grep -InaE \
  'ERR_INSUFFICIENT_RESOURCES|net::ERR_FAILED|service.?worker|openai\.chatgpt|codex|ERR_FILE_NOT_FOUND' \
  2>/dev/null \
| tail -n 300

如果日志中存在大量资源加载失败，同时关键 Renderer 的 Max open files 又是 1024，那么文件描述符限制仍然应作为优先排查方向。

二十二、一键检查脚本

可以将下面的内容保存为：

check-vscode-codex.sh

#!/usr/bin/env bash

echo "========== 当前 Shell 限制 =========="

printf 'soft nofile: '
ulimit -Sn

printf 'hard nofile: '
ulimit -Hn

echo
echo "========== VS Code 进程 =========="

mapfile -t pids < <(
  pgrep -f '^/usr/share/code/code' 2>/dev/null
)

if [ "${#pids[@]}" -eq 0 ]; then
  echo "未发现 VS Code 进程"
  exit 0
fi

for pid in "${pids[@]}"; do
  cmd="$(
    tr '\0' ' ' \
      < "/proc/$pid/cmdline" \
      2>/dev/null
  )"

  type="$(
    printf '%s' "$cmd" \
      | sed -n 's/.*--type=\([^ ]*\).*/\1/p'
  )"

  [ -n "$type" ] || type="main-or-helper"

  soft="$(
    awk '/Max open files/{print $4}' \
      "/proc/$pid/limits" \
      2>/dev/null
  )"

  hard="$(
    awk '/Max open files/{print $5}' \
      "/proc/$pid/limits" \
      2>/dev/null
  )"

  fd_count="$(
    find "/proc/$pid/fd" \
      -mindepth 1 \
      -maxdepth 1 \
      2>/dev/null \
    | wc -l
  )"

  printf \
    'PID=%-8s soft=%-8s hard=%-8s fd=%-6s type=%s\n' \
    "$pid" \
    "$soft" \
    "$hard" \
    "$fd_count" \
    "$type"
done

echo
echo "========== Codex 后台进程 =========="

pgrep -a -f '/openai\.chatgpt-.*/codex' \
  || echo "未发现 Codex 后台进程"

赋予执行权限：

chmod +x check-vscode-codex.sh

运行：

./check-vscode-codex.sh

二十三、回滚方法

如果不希望继续使用用户级启动器，可以执行回滚。

删除用户 desktop 文件：

rm -f ~/.local/share/applications/code.desktop

删除启动脚本：

rm -f ~/.local/bin/code-highfd

刷新桌面应用数据库：

update-desktop-database ~/.local/share/applications \
  2>/dev/null || true

然后：

从 Ubuntu Dock 移除 VS Code；
注销并重新登录；
从应用程序列表中重新固定系统默认 VS Code。

此前备份的缓存目录名称类似：

Service Worker.bak.时间
Cache.bak.时间
CachedData.bak.时间
GPUCache.bak.时间

确认新缓存长期正常后，可以手动删除旧备份。

二十四、本次排查中的关键经验

1. 本地和远程同时异常，不一定是 SSH

如果本地 VS Code 和 Remote-SSH 都会卡住，而 SSH 本身连接正常，应优先排查本地 Webview、Renderer 和桌面启动环境。

2. 删除缓存后恢复，不代表缓存是唯一根因

删除 Service Worker 只能证明缓存参与了故障，不代表底层资源限制已经解决。

3. `ulimit` 只影响当前 Shell 和子进程

在终端执行：

ulimit -Sn 65536

不会自动改变 Ubuntu Dock 启动的应用。

4. 新窗口可能仍然复用旧进程

如果旧 VS Code 没有退出，即使在高限制终端执行：

code --new-window

新窗口也可能继续属于旧的低限制进程。

5. 不能只检查 VS Code 主进程

VS Code 是多进程应用。主进程显示 1048576，并不代表 Renderer、zygote 和 utility 进程也相同。

6. 不要一开始就删除全部配置

直接删除以下目录风险很大：

~/.vscode
~/.vscode-server
~/.codex
~/.ssh

应先查看进程限制、日志、权限和缓存状态，再逐层排查。

二十五、最终结论

本次故障的完整因果链可以总结为：

Ubuntu 图形桌面启动 VS Code
        ↓
部分 VS Code/Electron 子进程继承 soft nofile=1024
        ↓
Codex Webview 加载文件、网络连接和通信通道
        ↓
部分资源无法继续打开
        ↓
Codex 页面停留在加载动画
        ↓
删除 Service Worker 后暂时恢复
        ↓
继续多开窗口后再次失败

最终解决流程为：

创建 code-highfd 启动脚本
        ↓
启动前执行 ulimit -Sn 65536
        ↓
用户级 code.desktop 指向该脚本
        ↓
完全退出旧 VS Code
        ↓
备份清理一次 Webview 缓存
        ↓
重新固定 Ubuntu Dock 图标
        ↓
Codex 本地与 Remote-SSH 多窗口恢复正常

一句话总结：

问题不是 Codex 登录失败，也不是 SSH 配置损坏，而是 Ubuntu 侧边栏启动的部分 VS Code 子进程仍受 soft nofile=1024 限制。通过为 VS Code 单独建立高文件描述符启动入口，可以解决 Codex 随机卡在加载页面的问题。

https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

Cursor+GitOps：自动化运维新姿势

Cursor+GitOps不是替代，而是增强从重复劳动到创造性工作的转变运维工程师的新定位：策略制定者与AI训练师开启智能化、自动化、自主化的运维新篇章。

AI编程社区

Codex++安全边界探秘：从模型能力到风险防御

2.1 超越代码补全：理解、生成与推理2.2 安全边界的多维构成数据隐私与训练数据泄露风险恶意代码生成与供应链攻击提示注入与越权操作模型偏见与公平性问题2.3 安全边界 vs. 能力边界：一个动态的博弈7.1 给开发者的安全编码建议7.2 给安全研究者的重点研究方向7.3 给企业技术决策者的风险评估清单7.4 关键资源与工具推荐hdf。