What causes "Image file not found: {path}" in iOfficeAI/OfficeCLI?

Verify the file exists at the exact path with an absolute path (e.g. '/home/user/images/logo.png').

iOfficeAI/OfficeCLI · error · FileNotFoundException

Image file not found: {path}

Error message

Image file not found: {path}

What it means

Thrown by ImageSource.ResolveFile when File.Exists(path) returns false. This is a FileNotFoundException (not ArgumentException), and it fires before any attempt to read the file or validate its contents. The path string is included verbatim in the message to help diagnose typos, relative-path issues, or working-directory mismatches.

Source

Thrown at src/officecli/Core/ImageSource.cs:69

        var ext = extension.TrimStart('.').ToLowerInvariant();
        return ext switch
        {
            "png" => ImagePartType.Png,
            "jpg" or "jpeg" => ImagePartType.Jpeg,
            "gif" => ImagePartType.Gif,
            "bmp" => ImagePartType.Bmp,
            "tif" or "tiff" => ImagePartType.Tiff,
            "emf" => ImagePartType.Emf,
            "wmf" => ImagePartType.Wmf,
            "svg" => ImagePartType.Svg,
            _ => throw new ArgumentException($"Unsupported image format: .{ext}. Supported: png, jpg, gif, bmp, tiff, emf, wmf, svg")
        };
    }

    private static (Stream, PartTypeInfo) ResolveFile(string path)
    {
        if (!File.Exists(path))
            throw new FileNotFoundException($"Image file not found: {path}");

        var contentType = ExtensionToContentType(Path.GetExtension(path));
        var ext = Path.GetExtension(path).TrimStart('.').ToLowerInvariant();

        // Magic-byte validation for raster formats. SVG (XML) / EMF / WMF are
        // intentionally skipped: SVG has no fixed magic, EMF/WMF have weaker
        // headers and TrySniffContentType doesn't cover them. Only validate
        // formats whose first 4 bytes are stable (png/jpg/gif/bmp/tiff).
        var rasterExts = new[] { "png", "jpg", "jpeg", "gif", "bmp", "tif", "tiff" };
        if (rasterExts.Contains(ext))
        {
            var bytes = File.ReadAllBytes(path);
            if (TrySniffContentType(bytes, out var sniffed))
            {
                if (!IsCompatible(sniffed, contentType))
                    throw new ArgumentException(
                        $"Image file '{path}' has extension .{ext} but magic bytes indicate {ContentTypeName(sniffed)}. " +
                        "Rename or convert the file.");

View on GitHub (pinned to 1ced45e900)

Solutions

Verify the file exists at the exact path with an absolute path (e.g. '/home/user/images/logo.png').
Check the working directory of the process and use an absolute path instead of a relative one.
If the file was recently moved or deleted, restore it or update the path.
On case-sensitive filesystems, ensure the path casing exactly matches the file on disk.

Example fix

// before — relative path fails in unexpected cwd
add image src='assets/logo.png' path='/body'

// after — absolute path
add image src='/home/user/project/assets/logo.png' path='/body'

Defensive patterns

Strategy: validation

Validate before calling

// Pre-check file existence before resolving
if (!File.Exists(path))
{
    Console.Error.WriteLine($"Image file not found: {path}");
    return;
}
var (stream, contentType) = ImageSource.Resolve(path);

Try / catch

try
{
    var (stream, contentType) = ImageSource.Resolve(path);
}
catch (FileNotFoundException ex) when (ex.Message.Contains("Image file not found"))
{
    // Prompt user for correct path or skip
}

Prevention

Always use absolute paths for image sources to avoid working-directory ambiguity.
Call File.Exists before invoking Resolve to provide your own error context.
In containerized environments, verify the path is mounted before referencing it.

When it happens

Trigger: Calling ImageSource.Resolve with a local file path that does not exist on disk. This includes: typoed paths, relative paths resolved against the wrong working directory, paths to files that were deleted between the time the command was constructed and when Resolve ran, and paths with incorrect casing on case-sensitive filesystems.

Common situations: An agent operating from a different working directory than expected, so a relative path doesn't resolve. A file path captured by a dump command that has since been moved or deleted. A containerized or sandboxed environment where the path is valid on the host but not mounted inside the container. Case-sensitivity issues when moving from Windows to Linux/macOS.

Related errors

AI-assisted analysis of iOfficeAI/OfficeCLI@1ced45e900 (2026-08-13). Data as JSON: /api/errors/89f0daab9ce37a7b. Report an issue: GitHub.