[Bug]: `container build` ignores default/relative build context in `mktemp` directory, but works with absolute path

[jakubkaczor]

I have done the following

• I have searched the existing issues
• If possible, I've reproduced the issue using the 'main' branch of this project

Steps to reproduce

cd "$(mktemp -d)"

cat > Dockerfile <<'EOF'
FROM debian:stable-slim
COPY . .
RUN cat Dockerfile
EOF

container build

The build fails with:

cat: Dockerfile: No such file or directory

The same happens with:

container build .

But this succeeds:

container build "$PWD"

In my specific example reproduction, the mktemp -d resolved to /var/folders/qf/ng024_6s5kn4z_sczdcdbbkh0000gn/T/tmp.3tuwoUOXS3.

Problem description

When building from a temporary directory created with mktemp -d, the build context appears to be empty if the context is specified implicitly or as ..

The following commands all produce an empty build context:

container build
container build .

However, providing the exact same directory as an absolute path works:

container build "$PWD"

The behavior does not occur when building from a normal directory such as ~/test.

Environment

- OS: ProductName:            macOS
      ProductVersion:         26.5.2
      BuildVersion:           25F84
- Container: container CLI version 1.0.0 (build: release, commit: ee848e3)

Code of Conduct

• I agree to follow this project's Code of Conduct

[am-saksham]

Hi! I'd love to work on this.
Since this is happening on macOS with mktemp -d, I suspect this is a symlink resolution issue. macOS maps /var to /private/var, so when the context is passed implicitly (.), the path archiver might be failing a strict string comparison without evaluating the symlink first.
I can investigate and put together a fix. Could you assign this to me?

[lakshitsoni26]

Hey @am-saksham! I was actually just trying to fix some of the failing integration tests (like testBuildSymlink and testCopyRenameFromStage) in the TestCLIBuilderSerial test suite. While debugging why those tests were failing, I ended up tracking down the root cause in URL+Extensions and BuildFSSync and realized it's the exact same bug causing this mktemp issue! I just opened #1922 to get the test suite green again, which resolves this issue as a side effect. Feel free to review it!

[svelez]

I hit a variant of this that's worth flagging before #1922 gets merged as the fix, since #1922 only covers part of this bug class.

Minimal repro (no mktemp needed):

#!/usr/bin/env bash
set -euo pipefail

testdir="reproduce-$RANDOM"
mkdir -p "$testdir/deep/context"
cd "$testdir"
echo hello > deep/context/helloworld.txt
cat <<EOM > Dockerfile
FROM busybox
COPY helloworld.txt /helloworld.txt
EOM

container build -f Dockerfile deep/context


ln -s deep linked
container build -f Dockerfile linked/context

The first build (real path, no symlink) succeeds. The second — identical
files, reached through a symlinked directory component (linked -> deep)
instead of the real path — fails with an empty build context:

#3 [internal] load .dockerignore
#3 transferring context: 2B done
#4 [internal] load build context
#4 transferring context: 2B done
#5 [linux/arm64/v8 1/2] COPY helloworld.txt /helloworld.txt
#5 ERROR: failed to calculate checksum of ref ...: "/helloworld.txt": not found

Same signature as the original report here — "load build context" transfers
essentially nothing and the subsequent COPY/ADD fails with "not found".
Reproduces every time, on both released v1.1.0 (commit 5973b9c) and current
main (commit 90be187 — the relevant source is unchanged between the two).

Environment

- OS: macOS 26.3.1 (25D2128)
- Xcode: 26.6 (17F113)
- Container: container CLI version 1.1.0 (build: release, commit: 5973b9c)
  (also reproduced building main @ 90be187 locally)

[jglogan]

This issue (both examples) should be fixed in the upcoming release.