bug: resolve_from() silently treats non-existent paths as image references

[johntmyers]

Agent Diagnostic

Loaded principal-engineer-reviewer skill to evaluate an external contributor's bug report from discussion #731. The reviewer confirmed the bug by tracing the code path in crates/openshell-cli/src/run.rs.

Findings:

• resolve_from() exists at run.rs:2479 and follows this resolution order:
  1. path.is_file() — checks if it's an existing file with "Dockerfile" in the name (line 2483)
  2. path.is_dir() — checks if it's an existing directory containing a Dockerfile (line 2506)
  3. value.contains('/') || value.contains(':') || value.contains('.') — falls through to treating the value as an image reference (line 2526)
  4. Otherwise, treat as a community sandbox name (line 2531)
• When a non-existent filesystem path is passed (e.g. --from /home/user/project/Dockerfile), steps 1 and 2 skip because neither is_file() nor is_dir() returns true, and step 3 matches because the path contains /.
• The path is then passed as-is to Kubernetes as a container image reference, which fails with an opaque InvalidImageName error.
• resolve_from() currently has zero unit tests.

Description

Actual behavior: When sandbox create --from /path/to/Dockerfile is given and the path doesn't exist, resolve_from() silently falls through to treating the path as a container image reference. Kubernetes then rejects it with InvalidImageName, giving the user no indication that the real problem is a missing file.

Expected behavior: If the value looks like a filesystem path (starts with /, ./, or ~/) but the path doesn't exist on disk, resolve_from() should return a clear error such as "Path does not exist: /path/to/Dockerfile".

Reproduction Steps

1. Run openshell sandbox create --from /nonexistent/path/Dockerfile
2. Observe that the CLI does not report a missing file
3. Kubernetes fails with InvalidImageName for /nonexistent/path/Dockerfile

Fix Approach

Add a path-existence check between step 2 (directory check) and step 3 (image-reference fallback) in resolve_from(), approximately line 2524:

• If the value starts with /, ./, or ~/ and the path does not exist, return an early error with a clear message.
• OCI image references never start with / or ./, so this heuristic has no false-positive risk for valid image refs.
• Add unit tests for resolve_from().

Environment

• Discovered on Intel Mac + Colima + Docker-wrapped openshell CLI
• Applicable to all platforms

Logs

InvalidImageName: /home/user/project/Dockerfile

[github-actions]

This issue appears to have been opened without an agent investigation.

OpenShell is an agent-first project - please point your coding agent at the repo and have it diagnose this before we triage. Your agent can load skills like debug-openshell-cluster, debug-inference, openshell-cli, and generate-sandbox-policy.

See CONTRIBUTING.md for the full workflow.

[letv1nnn]

This bug was fixed in #957.

The following checks the path for its validity before falling through to image-reference resolution.

// 3. Missing explicit local paths should fail locally. Otherwise values
// like `./Dockerfile` reach the gateway as image references and fail as
// Docker pull errors.
if value_looks_like_local_source(value) {
    return Err(miette::miette!(
        "local --from path does not exist: {}\n\
        Use an existing Dockerfile, a directory containing Dockerfile, or a container image reference.",
        path.display()
    ));
}

Covered by the following test:

#[test]
fn resolve_from_rejects_missing_explicit_dockerfile_path() {
    let temp = tempfile::tempdir().expect("failed to create tempdir");
    let missing = temp.path().join("Dockerfile");

    let err = resolve_from(missing.to_str().expect("temp path is not UTF-8"))
       .expect_err("expected missing Dockerfile path to be rejected");

    assert!(
        err.to_string().contains("local --from path does not exist"),
        "unexpected error: {err}"
    );
}