CodeWhale: image_analyze follows workspace symlinks, leaking external file bytes

let path_str = required_str(&input, "path")?;
let image_path = context.resolve_path(path_str)?;

resolve_path in crates/tui/src/tools/spec.rs:342-449 canonicalizes the candidate and rejects results whose canonical form does not start with the canonical workspace path:

if candidate.exists() {
    let canonical = candidate.canonicalize().map_err(...)?;
    if !canonical.starts_with(&workspace_canonical)
        && !self.is_trusted_external_path(&canonical)
    {
        return Err(ToolError::PathEscape { path: canonical });
    }
    ...
}

In the same symlink scenario, image_ocr, pandoc_convert, read_file, apply_patch, rlm_open, and fim all return ToolError::PathEscape because the canonical target falls outside the workspace. image_analyze is the lone caller that skips this check.

The tool declares ToolCapability::ReadOnly and does not override approval_requirement(). The trait default (crates/tui/src/tools/spec.rs:612-620) resolves ReadOnly to ApprovalRequirement::Auto. The engine then sets approval_required = spec.approval_requirement() != ApprovalRequirement::Auto, which is false for this tool (crates/tui/src/core/engine/turn_loop.rs:1159-1184). The model can invoke image_analyze on any turn without a user prompt.

The recent commit 2326220 fix(vision): reject rooted image paths on windows (2026-05-12) tightened the lexical guard to catch Windows drive prefixes, but the original review missed that the underlying problem is that this site never used resolve_path in the first place.

PoC

A standalone Cargo test reproduces the read-through. Save as crates/tui/tests/image_analyze_symlink_escape.rs:

use deepseek_tui::config::VisionModelConfig;
use deepseek_tui::tools::spec::{ToolContext, ToolSpec};
use deepseek_tui::vision::tools::ImageAnalyzeTool;
use serde_json::json;
use std::fs;
use tempfile::tempdir;

#[tokio::test]
#[cfg(unix)]
async fn image_analyze_follows_workspace_symlink_outside_workspace() {
    let outer = tempdir().unwrap();
    let workspace = outer.path().join("workspace");
    let outside = outer.path().join("outside");
    fs::create_dir_all(&workspace).unwrap();
    fs::create_dir_all(&outside).unwrap();

    // A file that the workspace boundary should keep the tool from reading.
    let secret = outside.join("secret.txt");
    fs::write(&secret, b"OUTSIDE-WORKSPACE-SECRET-MARKER").unwrap();

    // Pre-existing symlink in the workspace with an image extension.
    std::os::unix::fs::symlink(&secret, workspace.join("screenshot.png")).unwrap();

    let ctx = ToolContext::new(workspace);
    let tool = ImageAnalyzeTool::new(VisionModelConfig {
        model: "test".into(),
        api_key: Some("test".into()),
        base_url: Some("http://127.0.0.1:1/v1".into()),
    });

    // The execute call will fail at the HTTP layer because the mock endpoint
    // is unreachable, but read_image_file has already been called. Reach the
    // file-read step by asserting that the failure is the HTTP error, not a
    // PathEscape error from the resolver.
    let err = tool
        .execute(json!({"image_path": "screenshot.png"}), &ctx)
        .await
        .expect_err("expected HTTP failure after symlink read");
    let msg = format!("{err:?}");
    assert!(
        !msg.contains("PathEscape"),
        "symlink should have been refused before read; got {msg}"
    );
    // To prove the bytes actually left the process, point base_url at a
    // capturing wiremock instance and assert that the OUTSIDE-WORKSPACE-SECRET-MARKER
    // substring appears in the captured base64-decoded request body.
}

For comparison, the same workspace exercised via read_file returns ToolError::PathEscape:

#[tokio::test]
#[cfg(unix)]
async fn read_file_refuses_workspace_symlink_outside_workspace() {
    use deepseek_tui::tools::file::ReadFileTool;
    let outer = tempdir().unwrap();
    let workspace = outer.path().join("workspace");
    let outside = outer.path().join("outside");
    fs::create_dir_all(&workspace).unwrap();
    fs::create_dir_all(&outside).unwrap();
    fs::write(outside.join("secret.txt"), b"X").unwrap();
    std::os::unix::fs::symlink(outside.join("secret.txt"), workspace.join("link.txt")).unwrap();

    let ctx = ToolContext::new(workspace);
    let err = ReadFileTool
        .execute(json!({"path": "link.txt"}), &ctx)
        .await
        .expect_err("expected PathEscape");
    assert!(format!("{err:?}").contains("PathEscape"));
}

The fix is one line on crates/tui/src/vision/tools.rs:122:

- let resolved_path = context.workspace.join(image_path_buf);
+ let resolved_path = context.resolve_path(image_path)?;

resolve_path already handles the pre-join lexical checks (so the existing Path::new(image_path).components().any(...) block can also be removed), canonicalizes through symlinks, and re-checks workspace containment. The behavior the lexical guard already promises (path stays inside the workspace) is then actually delivered.

Impact

A workspace symlink whose name ends in .png, .jpg, .jpeg, .gif, .webp, or .bmp and whose target sits outside the workspace becomes a read primitive that the model can invoke without an approval prompt. The file bytes are base64-encoded into the image_url.url field of the chat-completion payload and POSTed to the configured vision endpoint along with the user's bearer token. Three exposure channels follow from a single invocation: the vision provider receives every byte of the target file in plaintext (most providers retain request bodies for abuse review or model training), any TLS-terminating corporate proxy on the egress path captures the same bytes, and any transparent middlebox with MITM visibility logs the payload. The preconditions are everyday workspace shapes: cloned repositories that ship symlinks to shared media (CI artifact bundles, photo libraries, design assets), a developer who staged an external file via ln -s, or a git clone with core.symlinks=true against a repository that includes such a link. Because the tool is auto-approved, a prompt-injection delivered through a poisoned README, fetched web page, or MCP server output can issue {"image_path": "screenshot.png"} and the bytes leave the machine on the same turn without any visible UI cue. The fix is identical to the pattern used by every other file-reading tool in this codebase, so the gap is a missed resolve_path call rather than a design tradeoff.