no chat task in context: run inside a chat task (MULTICA_TAS

Error message

no chat task in context: run inside a chat task (MULTICA_TASK_ID set) or pass --task <id>

What it means

The `attachment upload` CLI command needs to know which chat task owns the attachment. It first checks the --task flag, then falls back to client.TaskID (populated from the MULTICA_TASK_ID environment variable). When both are empty the command refuses to run because an attachment cannot be associated with any chat.

Source

Thrown at server/cmd/multica/cmd_attachment.go:74

	attachmentCmd.AddCommand(attachmentDownloadCmd)
	attachmentCmd.AddCommand(attachmentUploadCmd)

	attachmentDownloadCmd.Flags().StringP("output-dir", "o", ".", "Directory to save the downloaded file")
	attachmentUploadCmd.Flags().String("task", "", "Chat task id to attach to (defaults to MULTICA_TASK_ID)")
}

func runAttachmentUpload(cmd *cobra.Command, args []string) error {
	client, err := newAPIClient(cmd)
	if err != nil {
		return err
	}

	taskID, _ := cmd.Flags().GetString("task")
	if taskID == "" {
		taskID = client.TaskID
	}
	if taskID == "" {
		return fmt.Errorf("no chat task in context: run inside a chat task (MULTICA_TASK_ID set) or pass --task <id>")
	}

	path := args[0]
	if isHTTPURL(path) {
		return fmt.Errorf("upload accepts a local file path, not a URL: %s", path)
	}
	data, err := os.ReadFile(path)
	if err != nil {
		return fmt.Errorf("read file %s: %w", path, err)
	}

	ctx, cancel := context.WithTimeout(context.Background(), cli.AtLeastAPITimeout(60*time.Second))
	defer cancel()

	att, err := client.UploadChatAttachment(ctx, data, path, taskID)
	if err != nil {
		return fmt.Errorf("upload attachment: %w", err)
	}

View on GitHub (pinned to 2c0912b6ec)

Solutions

Pass the task explicitly: `multica attachment upload --task <task-id> <file>`
Export MULTICA_TASK_ID=<task-id> before running the command
Run the command from inside a chat task session so the daemon injects MULTICA_TASK_ID
If scripting, fetch a task id first (e.g. `multica task list`) and feed it to --task

Example fix

# before
multica attachment upload ./report.pdf
# -> no chat task in context...

# after
multica attachment upload --task 42 ./report.pdf
# or
MULTICA_TASK_ID=42 multica attachment upload ./report.pdf

Defensive patterns

Strategy: validation

Validate before calling

# shell: fail fast before calling upload
: "${MULTICA_TASK_ID:?no chat task in context: set MULTICA_TASK_ID or pass --task <id>}"

Prevention

Scripts that upload attachments should always pass --task explicitly instead of relying on ambient env
At script start, assert MULTICA_TASK_ID is set when running inside chat-task automation

When it happens

Trigger: Running `multica attachment upload <file>` outside a daemon-managed chat task with no --task flag and no MULTICA_TASK_ID in the environment (e.g. from a plain shell, CI, or a script that does not source the task env).

Common situations: Agent/automation scripts that reuse a snippet from a chat task but run it in a fresh terminal; users testing the CLI locally after reading docs that assume a chat-task context; MULTICA_TASK_ID lost because the command runs through sudo or a wrapper that scrubs env.

Related errors

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