# kubectl cp (from pod): Usage, Options & Common CI Errors

> kubectl cp pulling files out of a container to the runner. The tar dependency, path syntax, the leading-slash warning, and distroless failures in CI.

Source: https://latchkey.dev/learn/command-reference/kubectl-cp-from-pod  
Updated: 2026-06-25

Pull a report or artifact out of a running container to the runner.

kubectl cp in the pod-to-local direction extracts files from a container onto the CI runner - a coverage report, a generated bundle, a debug dump. The pod source path uses a namespace/pod:/path form and depends on tar inside the container.

## What it does

kubectl cp NS/POD:/path/in/container ./local/path copies files out by streaming a tar archive from the container, so the source container must have a tar binary on its PATH. -c selects the container in a multi-container pod. The remote path is interpreted inside the container; the local path is on the runner.

## Common usage

```Terminal
kubectl cp my-pod:/app/report.xml ./report.xml
kubectl cp my-ns/my-pod:/var/log/app.log ./app.log -c app
kubectl cp my-pod:/app/coverage ./coverage          # a whole directory
kubectl exec my-pod -- cat /app/report.xml > report.xml   # tar-free fallback
```

## Common errors in CI

"tar: not found" / "exec: \"tar\": executable file not found" is the defining failure on distroless or scratch images that ship no tar - fall back to kubectl exec my-pod -- cat /path > file for a single file, or copy into a debug sidecar that has tar. kubectl warns and strips a leading / from the remote path ("Removing leading '/' from member names"), which can land the file somewhere unexpected - it is a warning, not an error, but verify the destination. Copying a directory whose local parent does not exist fails; create the target dir first.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl cp (from pod): Usage, Options & Common CI Errors?

kubectl cp in the pod-to-local direction extracts files from a container onto the CI runner - a coverage report, a generated bundle, a debug dump. The pod source path uses a namespace/pod:/path form and depends on tar inside the container.

### What it does?

kubectl cp NS/POD:/path/in/container ./local/path copies files out by streaming a tar archive from the container, so the source container must have a tar binary on its PATH. -c selects the container in a multi-container pod. The remote path is interpreted inside the container; the local path is on the runner.

### Common errors in CI?

"tar: not found" / "exec: \"tar\": executable file not found" is the defining failure on distroless or scratch images that ship no tar - fall back to kubectl exec my-pod -- cat /path > file for a single file, or copy into a debug sidecar that has tar.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt