Reporter
External user reported on Chinese tech Twitter (May 1, 2026):
我用DeepSeek-TUI来解析youtube，出现了DNS的错误，请问有什么办法来处理吗？我使用claude code或者codex可以解析的。
(I use DeepSeek-TUI to parse YouTube and get a DNS error. Is there a way to handle this? I can use Claude Code or Codex to parse it.)
Error shown:
DNS resolution failed for YouTube. This is a network issue — the sandbox can't
reach YouTube's servers.
Root cause (verified)
Path: crates/tui/src/core/engine.rs:1198-1207 only elevates the sandbox policy in Yolo mode. In Agent mode (the default), ToolContext::elevated_sandbox_policy is None, so ShellManager falls back to its default policy:
crates/tui/src/sandbox/policy.rs:73-82 — SandboxPolicy::default() returns:
```rust
SandboxPolicy::WorkspaceWrite {
writable_roots: vec![],
network_access: false, // ← every shell exec blocked from the network
exclude_tmpdir: false,
exclude_slash_tmp: false,
}
```
On macOS, crates/tui/src/sandbox/seatbelt.rs:139-178 only emits the network-allow block when policy.has_network_access() is true — confirmed by the existing test (lines 327-338): `assert!(!result.contains("network-outbound"));`.
So with (deny default) and no (allow network-outbound) / (allow system-socket), every outbound socket call from a sandboxed shell command — including `getaddrinfo` — gets denied by the kernel. The first symptom users see is DNS failure.
This affects every shell command that needs network in Agent mode: `curl`, `wget`, `yt-dlp`, `pip install`, `npm install`, `cargo fetch`, `apt-get update`, …
Why Codex / Claude Code work for the same case
The user's comparison is correct: those tools either (a) don't sandbox shell exec by default, or (b) their default sandbox does not deny network. We inherited the codex-rs sandbox scaffolding but only the Yolo-mode elevation — Agent mode never grants network even though running shell commands itself is already approved by the user.
Proposed fix
Three-line change in `engine.rs::build_tool_context`: extend the elevated-policy branch to Agent mode with `network_access: true` (and keep workspace writes restricted to cwd). Plan mode stays untouched; Yolo mode stays at full access.
This keeps the existing NetworkPolicy layer (`crates/tui/src/network_policy.rs`) as the application-level allow/deny boundary for HTTP traffic — the right place — while removing the duplicate, blanket OS-level block on shell DNS that no one can opt out of without going to Yolo.
Tests: extend `engine` unit coverage to assert the Agent-mode tool context surfaces a sandbox policy with network access; flip the seatbelt-default test to confirm `network-outbound` is present once Agent-mode policy is the runtime default.
Acceptance
Reporter
External user reported on Chinese tech Twitter (May 1, 2026):
Root cause (verified)
Path:
crates/tui/src/core/engine.rs:1198-1207only elevates the sandbox policy in Yolo mode. In Agent mode (the default),ToolContext::elevated_sandbox_policyisNone, soShellManagerfalls back to its default policy:crates/tui/src/sandbox/policy.rs:73-82—SandboxPolicy::default()returns:```rust
SandboxPolicy::WorkspaceWrite {
writable_roots: vec![],
network_access: false, // ← every shell exec blocked from the network
exclude_tmpdir: false,
exclude_slash_tmp: false,
}
```
On macOS,
crates/tui/src/sandbox/seatbelt.rs:139-178only emits the network-allow block whenpolicy.has_network_access()is true — confirmed by the existing test (lines 327-338): `assert!(!result.contains("network-outbound"));`.So with
(deny default)and no(allow network-outbound)/(allow system-socket), every outbound socket call from a sandboxed shell command — including `getaddrinfo` — gets denied by the kernel. The first symptom users see is DNS failure.This affects every shell command that needs network in Agent mode: `curl`, `wget`, `yt-dlp`, `pip install`, `npm install`, `cargo fetch`, `apt-get update`, …
Why Codex / Claude Code work for the same case
The user's comparison is correct: those tools either (a) don't sandbox shell exec by default, or (b) their default sandbox does not deny network. We inherited the codex-rs sandbox scaffolding but only the Yolo-mode elevation — Agent mode never grants network even though running shell commands itself is already approved by the user.
Proposed fix
Three-line change in `engine.rs::build_tool_context`: extend the elevated-policy branch to Agent mode with `network_access: true` (and keep workspace writes restricted to cwd). Plan mode stays untouched; Yolo mode stays at full access.
This keeps the existing NetworkPolicy layer (`crates/tui/src/network_policy.rs`) as the application-level allow/deny boundary for HTTP traffic — the right place — while removing the duplicate, blanket OS-level block on shell DNS that no one can opt out of without going to Yolo.
Tests: extend `engine` unit coverage to assert the Agent-mode tool context surfaces a sandbox policy with network access; flip the seatbelt-default test to confirm `network-outbound` is present once Agent-mode policy is the runtime default.
Acceptance