multica-ai/multica · error

--attachment path %q resolves outside the current working di

Error message

--attachment path %q resolves outside the current working directory; attach files generated inside the task workdir rather than machine-shared paths like /tmp, where another run's stale file can be attached by mistake. Pass --allow-external-file to override.

What it means

A local --attachment path resolves outside the current working directory. This is the image-flavored twin of the text-file guard: it prevents attaching another run's (possibly another workspace's) stale file from machine-shared paths like /tmp. URL attachments are skipped earlier with a warning and never reach this check; --allow-external-file overrides it.

Source

Thrown at server/cmd/multica/cmd_issue.go:994

}

// ensureAttachmentWithinWorkdir applies the same workdir containment guard as
// --description-file / --content-file (MUL-4252) to a local --attachment path.
// An agent that writes a chart/report to a machine-shared path like /tmp and
// then attaches it could otherwise pick up another run's — possibly another
// workspace's — stale file (the image version of the /tmp/desc.md leak). URL
// values are filtered by the caller and never reach here. --allow-external-file
// overrides, mirroring the text-flag escape hatch.
func ensureAttachmentWithinWorkdir(cmd *cobra.Command, filePath string) error {
	if allow, _ := cmd.Flags().GetBool("allow-external-file"); allow {
		return nil
	}
	within, err := fileWithinWorkingDir(filePath)
	if err != nil {
		return fmt.Errorf("resolve --attachment path %q: %w", filePath, err)
	}
	if !within {
		return fmt.Errorf(
			"--attachment path %q resolves outside the current working directory; "+
				"attach files generated inside the task workdir rather than machine-shared "+
				"paths like /tmp, where another run's stale file can be attached by mistake. "+
				"Pass --allow-external-file to override.",
			filePath)
	}
	return nil
}

// pendingAttachment is a local --attachment file that passed URL filtering and
// the workdir guard and has been read into memory, ready to upload.
type pendingAttachment struct {
	path string
	data []byte
}

// collectLocalAttachments validates and reads ALL local --attachment paths up
// front, before any upload. URL-shaped values are warned and skipped (the API

View on GitHub (pinned to 2c0912b6ec)

Solutions

1. Generate the attachment inside the task workdir (e.g. ./chart.png) and attach that path.
2. If attaching an outside file is deliberate and the staleness risk is accepted, add --allow-external-file.
3. Use realpath on the path to see where it physically resolves — the guard follows symlinks.
4. Confirm the process CWD matches the directory containing the artifacts.

Example fix

# before
mv report.png /tmp/
multica issue create --title T --attachment /tmp/report.png
# after
multica issue create --title T --attachment ./report.png

# generate attachments in the workdir and verify containment
 case "$(realpath "$ATTACH")" in "$(realpath .)"/*) ;; *) echo "outside workdir — move it or use --allow-external-file" >&2; exit 1;; esac

When it happens

Trigger: Running `multica issue create --attachment /tmp/chart.png` or any path that, after symlink resolution on both sides, lands outside the CWD — without --allow-external-file.

Common situations: Agents writing charts/reports to /tmp then attaching them; parallel CI runs sharing a temp dir where run A attaches run B's screenshot; workdir symlinks pointing at outside directories.

Related errors

• --%s path %q resolves outside the current working directory;
• resolve --attachment path %q: %w
• read attachment %s: %w
• file not found: %w
• unsupported file format %q: must be .png, .jpg, .jpeg, .gif,

AI-assisted analysis of multica-ai/multica@2c0912b6ec (2026-08-15). Data as JSON: /api/errors/c4cf00b4d3b12527. Report an issue: GitHub.