multica-ai/multica · error
file content for --%s is empty
Error message
file content for --%s is empty
What it means
The CLI was given a --description-file / --content-file style flag whose target file exists and is readable, but after trimming a single trailing newline its content is empty. The CLI refuses to substitute empty content for the flag because that would silently wipe or no-op the field. This is a fail-fast guard so an empty file is reported instead of silently posting an empty description.
Source
Thrown at server/cmd/multica/cmd_issue.go:82
return "", false, fmt.Errorf("read stdin for --%s: %w", stdinFlag, err)
}
body := strings.TrimSuffix(string(data), "\n")
if body == "" {
return "", false, fmt.Errorf("stdin content for --%s is empty", stdinFlag)
}
return body, true, nil
}
if filePath != "" {
if err := ensureFileFlagWithinWorkdir(cmd, fileFlag, flagName, filePath); err != nil {
return "", false, err
}
data, err := os.ReadFile(filePath)
if err != nil {
return "", false, fmt.Errorf("read file for --%s: %w", fileFlag, err)
}
body := strings.TrimSuffix(string(data), "\n")
if body == "" {
return "", false, fmt.Errorf("file content for --%s is empty", fileFlag)
}
return body, true, nil
}
if inline == "" {
return "", false, nil
}
return util.UnescapeBackslashEscapes(inline), true, nil
}
// ensureFileFlagWithinWorkdir fails closed when a --<name>-file path resolves
// outside the current working directory, unless --allow-external-file is set.
//
// Agent task workdirs are isolated per profile and per task; machine-shared
// scratch paths like /tmp are not. MUL-4252 traced a cross-environment context
// leak to exactly this gap: a quick-create run wrote its description to a fixed
// /tmp/desc.md, the write silently failed because a *different* environment's
// run had left a stale file there minutes earlier, and --description-file then
// fed that stale content into the new issue. Requiring the file to live underView on GitHub (pinned to 2c0912b6ec)
Solutions
- Inspect the file (wc -c / cat -A) and fix the upstream step that was supposed to write the description so it produces real content.
- If the empty file is itself unexpected, regenerate it and re-run the command.
- If you intentionally have no content, drop the --*-file flag entirely instead of pointing it at an empty file.
- For trivial one-line content, use the inline flag (e.g. --description "text") instead of a file.
Example fix
# before printf '' > desc.md multica issue create --title "Fix login" --description-file desc.md # after printf 'Login fails when session expires.' > desc.md multica issue create --title "Fix login" --description-file desc.md
Defensive patterns
Strategy: validation
Validate before calling
# before invoking:
[ -s "$DESC_FILE" ] || { echo "description file empty: $DESC_FILE" >&2; exit 1; }
# -s is true only for non-empty files; also catches the missing-file case early Prevention
- Generate content files with set -euo pipefail so a failed generator aborts before the CLI runs.
- Never point --*-file at a file you haven't just written in the same script.
- Prefer inline --description for short content; reserve file flags for multi-line bodies.
When it happens
Trigger: Running `multica issue create --description-file <path>` (or any *-file flag handled by this helper) where the file is 0 bytes or contains only a single newline. The path must already pass the workdir guard and os.ReadFile, so the file exists and is readable but body == "" after strings.TrimSuffix(data, "\n").
Common situations: Agent or script pipelines that write a description to a temp file and the upstream generator (editor, jq, another command) produced empty output; a heredoc that failed to capture anything; a truncated file from a killed process; a file containing only a blank line.
Related errors
- --title is required
- multica CLI version not reported by daemon
- --cutoff is required; use the hosted deployment time of the
- parse --cutoff as RFC3339: %w
- --cutoff must be before now; refusing a future cutoff becaus
AI-assisted analysis of multica-ai/multica@2c0912b6ec (2026-08-15).
Data as JSON: /api/errors/1a6828dd87c3e4fd.
Report an issue: GitHub.