ServerBox 设备本机终端全解析本地 Shell 与 Linux 用户态的实现原理与实战指南【免费下载链接】flutter_server_boxServerBox - server status toolbox项目地址: https://gitcode.com/GitHub_Trending/fl/flutter_server_box本机终端Local Terminal是 ServerBox 在终端页中内置的一组特殊入口它排在所有远程服务器之前直接在运行 App 的设备上打开一个 Shell 或一套完整的 Linux 用户态环境。本文以 local-terminal.md 为骨架结合 local_shell.dart、android_rootfs.dart、ios_rootfs.dart 等源码实现系统讲解本机 Shell 与 Linux 用户态在各平台上的可用性、底层原理、安装与隔离机制以及它与普通服务器终端的关键差异。本机终端是什么终端页里无需凭据的两个入口当当前构建版本包含相应能力时终端页的服务器列表之前会先列出两类本机条目本机 ShellShell on this device运行在 ServerBox 所在设备上的一个交互式 ShellLinux 用户态Linux userland由 ServerBox 安装的一套独立 Linux 环境默认发行版为 Alpine。它们之所以排在最前面原因很简单设备永远可达且这些入口不需要任何凭据。在源码中这一顺序体现在终端选择页 tab_add.dart页面先渲染CenterGreyTitle(libL10n.device)下的设备 Shell 行再渲染Linux (Beta)标题下的用户态行最后才是服务器列表。注释明确写道First, and for the same reason the file tab lists it first: it is always reachable, and it needs no credential to be.它总是可达的且不需要任何凭据就能做到。需要强调的是这些功能完全取决于构建配置。一个构建可能只带本机 Shell、只带 Alpine 用户态、两者都带或两者都不带。如果终端页里看不到某个条目说明当前构建不包含该能力——源码中LocalShellBackend.isSupported与Rootfs.isAvailable正是 UI 判断是否渲染这些入口的依据。本机 Shell各平台可用性与$SHELL的选择逻辑平台可用性总览平台可用性Linux、Windows可用macOSDMG 构建可用macOSApp Store 构建不可用Android可用但 Shell 能力与桌面端不同iOS不可用在支持选择 Shell 的平台上App 使用$SHELL环境变量因此本机 Shell 通常与你终端应用打开的是同一个 Shell。这个逻辑在 local_shell.dart 的shellPath中实现static String get shellPath { if (Platform.isWindows) { return Platform.environment[COMSPEC] ?? cmd.exe; } if (Platform.isAndroid) return /system/bin/sh; final preferred Platform.environment[SHELL]; if (preferred ! null preferred.isNotEmpty) return preferred; return /bin/sh; }Windows读取COMSPEC通常指向cmd.exe未设置时回退到cmd.exeAndroid固定使用/system/bin/sh——这是 toybox 提供的极简 ShellLinux/macOS优先$SHELL未设置时回退到/bin/sh。代码注释点明了为什么坚持$SHELL而非硬编码路径a terminal that ignores which shell someone chose is a terminal they have toexecout of every time they open it忽略用户所选 Shell 的终端每次打开都得手动exec换出去。为什么 App Store 的 macOS 构建没有本机 ShellApp Store 的 macOS 构建无法提供本机 Shell。它运行在沙箱中而沙箱内的进程无法打开伪终端pseudo-terminal因此 App 会省略这个条目。DMG 构建未加沙箱可以正常提供。local_shell.dart 的注释记录了实测细节沙箱内Process.run可以成功但forkpty的子进程在exec之前就以 255 退出无论是使用主目录相对路径还是/dev/例外都无法改变结果。有趣的是这一判断是在运行时询问当前进程Pfs.isMacSandboxed而非编译期写死所以同一个二进制在两种环境下都会如实反映沙箱限制。DMG 构建的签名配置见 macos/Runner/ReleaseDmg.entitlements它不带沙箱 entitlement。为什么 iOS 没有本机 ShelliOS 不提供本机 Shell。App Store 应用无法启动进程不能fork/exec且其沙箱容器内根本没有/bin/sh可供启动。LocalShellBackend.isSupported的第一条判断就是if (Platform.isIOS) return false;。Android 本机 Shell 的特殊性Android 虽然可用但其 Shell 是 toybox——没有包管理器能力也远逊于桌面端。代码注释直言what Android hands over is a good deal less than a desktopsAndroid 交出的是一个比桌面少得多的东西。此外Android 应用没有HOMEShell 会继承进程工作目录并打开在只读且空无一物的/。因此 local_shell.dart 把应用自己的文档目录Paths.doc当作设备主目录并将其导出为HOME——否则cd无参数和命令中的~都会指向/。Linux 用户态移动端获得完整 Linux 环境的两条技术路线当平台不提供 Shell或其本机 Shell 能力受限时ServerBox 可以安装一套独立的 Linux 用户态。当前默认发行版为 Alpine 3.22.5App 的发行版列表还可能提供其他发行版与版本包括 Debian 和 Ubuntu。在终端页中它显示为发行版 版本如Alpine 3.22.5与本机 Shell 并排因为两者都运行在同一台设备上。发行版与版本在安装时选定之后的更新停留在同一 profile 内不会提供新的选择机会。这对应源码中更新reinstall保持 id 与 label仅替换文件系统的设计——见 android_rootfs.dart 的install与 ios_rootfs.dart 的注释。Android 与 iOS 使用两种截然不同的实现Android解包一个真实的 Linux rootfs并通过proot进入。当前构建支持 arm64rootfs 以 tarball 形式下载并针对固定 digestSHA-256进行校验iOS无法直接启动进程因此 App 内嵌了一个 Linux 解释器ish-arm64。用户态就是该解释器所使用的文件系统。Androidproot 绕过 execve 限制Android 侧的关键限制是目标 API 29 及以上的应用不得在自己的数据目录内execve文件。proot绕开了这一限制——它从不直接对 guest 二进制执行execve而是携带一个 loader将 guest ELF 映射到内存并把控制权交给 guest 自己的解释器因此宿主机无需具备运行 musl 二进制的能力Android 的 linker 无法运行 musl这一点在integration_test/android_exec_test.dart中有实测验证。proot本体存放在原生库目录App 唯一可执行的位置由仓库外的scripts/build-proot-android.sh构建。它只为 arm64 构建rootfs 亦然所以isAvailable同时是 32 位或 x86 设备说不的方式——它们在自己的 ABI 目录里找不到libproot.so。进入 rootfs 的实际命令在enter()中构造android_rootfs.dartproot -r root -b /dev -b /proc -b /sys -w /root --kill-on-exit -0 --link2symlink [shell | /bin/sh -lc command]其中-0让 guest 进程相信自己是 root这是apk能工作的前提-w /root提供可写的 home而--link2symlink是 termux/proot 的扩展用于把硬链接解析为符号链接——因为 Android 拒绝在应用私有数据目录内执行link()没有这个扩展apk add go会在 gcc 的硬链接成员上报Permission denied。交互式终端会遵循用户设置的linuxShell而一次性命令固定使用/bin/sh -lc以保证 App 与 Agent 解析输出的一致性。guest 环境变量同样有讲究android_rootfs.dartPATH必须重写为 rootfs 内部的路径并显式设置PROOT_TMP_DIR与PROOT_LOADER——否则 proot 会退回它试图避免的execve路径并报权限错误。安装管线固定 digest、原子替换与 tar 安全校验无论 Android 还是 iOSrootfs 安装都是一条严谨的下载—校验—解包管线。以 Android 的 android_rootfs.dart 为例先下载到 staging 目录.id.install-短id下载中断、digest 不匹配或解包失败时绝不触碰现存系统下载后计算流式 SHA-256与清单中固定的sha256比对不一致即丢弃。代码注释强调The tarball is executable code fetched over the network and then run; the digest is the only thing that makes that different from running whatever the connection handed back.tarball 是从网络获取的可执行代码digest 是它与运行连接返回的任何东西之间唯一的区别。解包交由系统自带的/system/bin/tar完成它是系统二进制所以可以执行、解压数千文件更快且能恢复让/bin/sh指向 busybox 的符号链接解包前会先用 rootfs_tar_utils.dart 提供的共享校验逻辑逐条验证 tar 条目拒绝路径逃逸、指向符号链接祖先的条目与不安全的硬链接目标完成后写入 marker 文件目录扫描scan()只认带 marker 的 profile保证半成品永远不会被当成已安装系统。iOSish-arm64 解释器iOS 侧的问题与 Android 相反这里没有fork/exec沙箱内也没有/bin/sh根本没有可以进入rootfs 的东西。答案是 ish-arm64 解释器——它将 guest AArch64 指令分派到预编译的原生 gadgets运行时不写机器码iOS 不授予 JIT entitlement也从不把 guest 二进制交给内核。引擎用 C 编写链接进 App通过ios/Runner/ish/sbm_ish.h中的八个函数以 FFI 方式调用ios_rootfs.dart。它只在SBM_ISH 1的构建中存在——ios/Flutter/Ish.xcconfig中的开关让不带引擎的构建仅一步之遥以备 App Store 审核需要。iOS 侧在 Dart 中完成解包因为 iOS 无法启动tar进程并要求所有目录强制 owner rwx 位——因为 guest 以宿主的单一非特权 uid 运行rootfs 里 0555 的目录如 Rocky 的/usr/bin会让包管理器无法创建临时文件。发行版清单默认值与可选版本rootfs 的发布清单内置于 assets/rootfs_manifest.json随 App 打包作为首次运行、离线或远程清单校验失败时的兜底。当前清单定义了三种发行版发行版包管理器默认镜像当前列出的版本Alpineapkdl-cdn.alpinelinux.org3.22.5分支 v3.22、3.21.7Ubuntuaptarchive.ubuntu.com26.04resolute、24.04.4nobleRocky Linuxdnfdl.rockylinux.org9.8、10.2每个版本都带sha256、size_bytes、layoutplain或oci与compressiongzip/xz。清单注释特别解释了为什么默认分支停留在 Alpine 3.22 而不是最新版android_rootfs.dart3.23 及以后版本的 apk-tools 3 在 Android proot 下访问仓库时全部报Permission denied在 API 36 上实测同一 rootfs 从本地文件仓库安装正常busybox wget 也能取到同样的 URL3.22 是带 apk-tools 2.14 的最后一个分支工作正常。integration_test/rootfs_shell_test.dart会通过网络安装一个包来监测这一变化。典型使用场景在没有 curl、dig、ssh、jq 的手机上使用这些工具——Android 的 toybox 和 iOS 的沙箱都缺这些东西执行不想直接跑在生产服务器上的临时性工作为 Agent 提供一个与设备文件系统隔离的执行目标详见 Agent 文档。每个用户态都是对应发行版的标准环境包管理也使用各自原生的包管理器Alpine 用apk addDebian/Ubuntu 用apt installRocky 用dnf。源码中LinuxDistro.packageManagerlinux_distro.dart会在更新警告中指名道姓——因为替换一套系统会摧毁包管理器写入的所有东西对 Ubuntu 用户说apk是在说一个他们从未敲过的命令。文件系统隔离移动端与桌面端语义不同的根源Alpine 用户态拥有自己的文件系统无法读取手机存储、App 数据、私钥或用户文件。这正是Run commands on this device在本设备上运行命令在移动端与桌面端含义不同的原因移动端命令运行在隔离的用户态里碰不到设备上的任何个人文件桌面端命令直接使用电脑自身的 Shell拥有普通用户权限。从代码结构看两者共享同一套 ShellBackend 接口——LocalShellBackend(inRootfs: false)打开平台 ShellinRootfs: true时经由AndroidRootfs.enter()进入用户态iOS 则走IshShellBackend。终端仿真器、虚拟键盘与标签页全部共享改变的只是字节流的来源。与服务器终端的关键差异本机 Shell 与普通 SSH 服务器终端相比有几点本质不同不校验主机密钥host key本地进程无需身份验证不重连没有像 SSH 那样的断线重连机制关闭即结束不出现在服务器列表与状态图表中它只是一个终端会话不是一个被监控的服务器。从实现角度local_shell.dart 将本机 Shell 定位为字节从哪来的第三种答案除 SSH 与 monitor agent 的 PTY 之外Nothing above ShellBackend changes: a terminal does not have to know that this shell needed no network at all.ShellBackend 之上的任何东西都不变终端无需知道这个 Shell 完全不需要网络。另外本机 Shell 的supportsExec恒为true——本地进程可以再启动另一个进程所以依赖第二通道的能力tmux、AI 助手的探测在这里同样可用而本地会话的关闭会向整个进程组发送 SIGHUP3 秒后 SIGKILL 兜底确保top、编辑器、构建任务等前台进程不会在终端消失后残留。【免费下载链接】flutter_server_boxServerBox - server status toolbox项目地址: https://gitcode.com/GitHub_Trending/fl/flutter_server_box创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ServerBox 设备本机终端全解析：本地 Shell 与 Linux 用户态的实现原理与实战指南
ServerBox 设备本机终端全解析本地 Shell 与 Linux 用户态的实现原理与实战指南【免费下载链接】flutter_server_boxServerBox - server status toolbox项目地址: https://gitcode.com/GitHub_Trending/fl/flutter_server_box本机终端Local Terminal是 ServerBox 在终端页中内置的一组特殊入口它排在所有远程服务器之前直接在运行 App 的设备上打开一个 Shell 或一套完整的 Linux 用户态环境。本文以 local-terminal.md 为骨架结合 local_shell.dart、android_rootfs.dart、ios_rootfs.dart 等源码实现系统讲解本机 Shell 与 Linux 用户态在各平台上的可用性、底层原理、安装与隔离机制以及它与普通服务器终端的关键差异。本机终端是什么终端页里无需凭据的两个入口当当前构建版本包含相应能力时终端页的服务器列表之前会先列出两类本机条目本机 ShellShell on this device运行在 ServerBox 所在设备上的一个交互式 ShellLinux 用户态Linux userland由 ServerBox 安装的一套独立 Linux 环境默认发行版为 Alpine。它们之所以排在最前面原因很简单设备永远可达且这些入口不需要任何凭据。在源码中这一顺序体现在终端选择页 tab_add.dart页面先渲染CenterGreyTitle(libL10n.device)下的设备 Shell 行再渲染Linux (Beta)标题下的用户态行最后才是服务器列表。注释明确写道First, and for the same reason the file tab lists it first: it is always reachable, and it needs no credential to be.它总是可达的且不需要任何凭据就能做到。需要强调的是这些功能完全取决于构建配置。一个构建可能只带本机 Shell、只带 Alpine 用户态、两者都带或两者都不带。如果终端页里看不到某个条目说明当前构建不包含该能力——源码中LocalShellBackend.isSupported与Rootfs.isAvailable正是 UI 判断是否渲染这些入口的依据。本机 Shell各平台可用性与$SHELL的选择逻辑平台可用性总览平台可用性Linux、Windows可用macOSDMG 构建可用macOSApp Store 构建不可用Android可用但 Shell 能力与桌面端不同iOS不可用在支持选择 Shell 的平台上App 使用$SHELL环境变量因此本机 Shell 通常与你终端应用打开的是同一个 Shell。这个逻辑在 local_shell.dart 的shellPath中实现static String get shellPath { if (Platform.isWindows) { return Platform.environment[COMSPEC] ?? cmd.exe; } if (Platform.isAndroid) return /system/bin/sh; final preferred Platform.environment[SHELL]; if (preferred ! null preferred.isNotEmpty) return preferred; return /bin/sh; }Windows读取COMSPEC通常指向cmd.exe未设置时回退到cmd.exeAndroid固定使用/system/bin/sh——这是 toybox 提供的极简 ShellLinux/macOS优先$SHELL未设置时回退到/bin/sh。代码注释点明了为什么坚持$SHELL而非硬编码路径a terminal that ignores which shell someone chose is a terminal they have toexecout of every time they open it忽略用户所选 Shell 的终端每次打开都得手动exec换出去。为什么 App Store 的 macOS 构建没有本机 ShellApp Store 的 macOS 构建无法提供本机 Shell。它运行在沙箱中而沙箱内的进程无法打开伪终端pseudo-terminal因此 App 会省略这个条目。DMG 构建未加沙箱可以正常提供。local_shell.dart 的注释记录了实测细节沙箱内Process.run可以成功但forkpty的子进程在exec之前就以 255 退出无论是使用主目录相对路径还是/dev/例外都无法改变结果。有趣的是这一判断是在运行时询问当前进程Pfs.isMacSandboxed而非编译期写死所以同一个二进制在两种环境下都会如实反映沙箱限制。DMG 构建的签名配置见 macos/Runner/ReleaseDmg.entitlements它不带沙箱 entitlement。为什么 iOS 没有本机 ShelliOS 不提供本机 Shell。App Store 应用无法启动进程不能fork/exec且其沙箱容器内根本没有/bin/sh可供启动。LocalShellBackend.isSupported的第一条判断就是if (Platform.isIOS) return false;。Android 本机 Shell 的特殊性Android 虽然可用但其 Shell 是 toybox——没有包管理器能力也远逊于桌面端。代码注释直言what Android hands over is a good deal less than a desktopsAndroid 交出的是一个比桌面少得多的东西。此外Android 应用没有HOMEShell 会继承进程工作目录并打开在只读且空无一物的/。因此 local_shell.dart 把应用自己的文档目录Paths.doc当作设备主目录并将其导出为HOME——否则cd无参数和命令中的~都会指向/。Linux 用户态移动端获得完整 Linux 环境的两条技术路线当平台不提供 Shell或其本机 Shell 能力受限时ServerBox 可以安装一套独立的 Linux 用户态。当前默认发行版为 Alpine 3.22.5App 的发行版列表还可能提供其他发行版与版本包括 Debian 和 Ubuntu。在终端页中它显示为发行版 版本如Alpine 3.22.5与本机 Shell 并排因为两者都运行在同一台设备上。发行版与版本在安装时选定之后的更新停留在同一 profile 内不会提供新的选择机会。这对应源码中更新reinstall保持 id 与 label仅替换文件系统的设计——见 android_rootfs.dart 的install与 ios_rootfs.dart 的注释。Android 与 iOS 使用两种截然不同的实现Android解包一个真实的 Linux rootfs并通过proot进入。当前构建支持 arm64rootfs 以 tarball 形式下载并针对固定 digestSHA-256进行校验iOS无法直接启动进程因此 App 内嵌了一个 Linux 解释器ish-arm64。用户态就是该解释器所使用的文件系统。Androidproot 绕过 execve 限制Android 侧的关键限制是目标 API 29 及以上的应用不得在自己的数据目录内execve文件。proot绕开了这一限制——它从不直接对 guest 二进制执行execve而是携带一个 loader将 guest ELF 映射到内存并把控制权交给 guest 自己的解释器因此宿主机无需具备运行 musl 二进制的能力Android 的 linker 无法运行 musl这一点在integration_test/android_exec_test.dart中有实测验证。proot本体存放在原生库目录App 唯一可执行的位置由仓库外的scripts/build-proot-android.sh构建。它只为 arm64 构建rootfs 亦然所以isAvailable同时是 32 位或 x86 设备说不的方式——它们在自己的 ABI 目录里找不到libproot.so。进入 rootfs 的实际命令在enter()中构造android_rootfs.dartproot -r root -b /dev -b /proc -b /sys -w /root --kill-on-exit -0 --link2symlink [shell | /bin/sh -lc command]其中-0让 guest 进程相信自己是 root这是apk能工作的前提-w /root提供可写的 home而--link2symlink是 termux/proot 的扩展用于把硬链接解析为符号链接——因为 Android 拒绝在应用私有数据目录内执行link()没有这个扩展apk add go会在 gcc 的硬链接成员上报Permission denied。交互式终端会遵循用户设置的linuxShell而一次性命令固定使用/bin/sh -lc以保证 App 与 Agent 解析输出的一致性。guest 环境变量同样有讲究android_rootfs.dartPATH必须重写为 rootfs 内部的路径并显式设置PROOT_TMP_DIR与PROOT_LOADER——否则 proot 会退回它试图避免的execve路径并报权限错误。安装管线固定 digest、原子替换与 tar 安全校验无论 Android 还是 iOSrootfs 安装都是一条严谨的下载—校验—解包管线。以 Android 的 android_rootfs.dart 为例先下载到 staging 目录.id.install-短id下载中断、digest 不匹配或解包失败时绝不触碰现存系统下载后计算流式 SHA-256与清单中固定的sha256比对不一致即丢弃。代码注释强调The tarball is executable code fetched over the network and then run; the digest is the only thing that makes that different from running whatever the connection handed back.tarball 是从网络获取的可执行代码digest 是它与运行连接返回的任何东西之间唯一的区别。解包交由系统自带的/system/bin/tar完成它是系统二进制所以可以执行、解压数千文件更快且能恢复让/bin/sh指向 busybox 的符号链接解包前会先用 rootfs_tar_utils.dart 提供的共享校验逻辑逐条验证 tar 条目拒绝路径逃逸、指向符号链接祖先的条目与不安全的硬链接目标完成后写入 marker 文件目录扫描scan()只认带 marker 的 profile保证半成品永远不会被当成已安装系统。iOSish-arm64 解释器iOS 侧的问题与 Android 相反这里没有fork/exec沙箱内也没有/bin/sh根本没有可以进入rootfs 的东西。答案是 ish-arm64 解释器——它将 guest AArch64 指令分派到预编译的原生 gadgets运行时不写机器码iOS 不授予 JIT entitlement也从不把 guest 二进制交给内核。引擎用 C 编写链接进 App通过ios/Runner/ish/sbm_ish.h中的八个函数以 FFI 方式调用ios_rootfs.dart。它只在SBM_ISH 1的构建中存在——ios/Flutter/Ish.xcconfig中的开关让不带引擎的构建仅一步之遥以备 App Store 审核需要。iOS 侧在 Dart 中完成解包因为 iOS 无法启动tar进程并要求所有目录强制 owner rwx 位——因为 guest 以宿主的单一非特权 uid 运行rootfs 里 0555 的目录如 Rocky 的/usr/bin会让包管理器无法创建临时文件。发行版清单默认值与可选版本rootfs 的发布清单内置于 assets/rootfs_manifest.json随 App 打包作为首次运行、离线或远程清单校验失败时的兜底。当前清单定义了三种发行版发行版包管理器默认镜像当前列出的版本Alpineapkdl-cdn.alpinelinux.org3.22.5分支 v3.22、3.21.7Ubuntuaptarchive.ubuntu.com26.04resolute、24.04.4nobleRocky Linuxdnfdl.rockylinux.org9.8、10.2每个版本都带sha256、size_bytes、layoutplain或oci与compressiongzip/xz。清单注释特别解释了为什么默认分支停留在 Alpine 3.22 而不是最新版android_rootfs.dart3.23 及以后版本的 apk-tools 3 在 Android proot 下访问仓库时全部报Permission denied在 API 36 上实测同一 rootfs 从本地文件仓库安装正常busybox wget 也能取到同样的 URL3.22 是带 apk-tools 2.14 的最后一个分支工作正常。integration_test/rootfs_shell_test.dart会通过网络安装一个包来监测这一变化。典型使用场景在没有 curl、dig、ssh、jq 的手机上使用这些工具——Android 的 toybox 和 iOS 的沙箱都缺这些东西执行不想直接跑在生产服务器上的临时性工作为 Agent 提供一个与设备文件系统隔离的执行目标详见 Agent 文档。每个用户态都是对应发行版的标准环境包管理也使用各自原生的包管理器Alpine 用apk addDebian/Ubuntu 用apt installRocky 用dnf。源码中LinuxDistro.packageManagerlinux_distro.dart会在更新警告中指名道姓——因为替换一套系统会摧毁包管理器写入的所有东西对 Ubuntu 用户说apk是在说一个他们从未敲过的命令。文件系统隔离移动端与桌面端语义不同的根源Alpine 用户态拥有自己的文件系统无法读取手机存储、App 数据、私钥或用户文件。这正是Run commands on this device在本设备上运行命令在移动端与桌面端含义不同的原因移动端命令运行在隔离的用户态里碰不到设备上的任何个人文件桌面端命令直接使用电脑自身的 Shell拥有普通用户权限。从代码结构看两者共享同一套 ShellBackend 接口——LocalShellBackend(inRootfs: false)打开平台 ShellinRootfs: true时经由AndroidRootfs.enter()进入用户态iOS 则走IshShellBackend。终端仿真器、虚拟键盘与标签页全部共享改变的只是字节流的来源。与服务器终端的关键差异本机 Shell 与普通 SSH 服务器终端相比有几点本质不同不校验主机密钥host key本地进程无需身份验证不重连没有像 SSH 那样的断线重连机制关闭即结束不出现在服务器列表与状态图表中它只是一个终端会话不是一个被监控的服务器。从实现角度local_shell.dart 将本机 Shell 定位为字节从哪来的第三种答案除 SSH 与 monitor agent 的 PTY 之外Nothing above ShellBackend changes: a terminal does not have to know that this shell needed no network at all.ShellBackend 之上的任何东西都不变终端无需知道这个 Shell 完全不需要网络。另外本机 Shell 的supportsExec恒为true——本地进程可以再启动另一个进程所以依赖第二通道的能力tmux、AI 助手的探测在这里同样可用而本地会话的关闭会向整个进程组发送 SIGHUP3 秒后 SIGKILL 兜底确保top、编辑器、构建任务等前台进程不会在终端消失后残留。【免费下载链接】flutter_server_boxServerBox - server status toolbox项目地址: https://gitcode.com/GitHub_Trending/fl/flutter_server_box创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考