Jobs reference: labels, outcomes and settings¶

Failure labels, outcome classes, every setting, tainted jobs and the security notes. Part of jobs.

Failure labels¶

In the Friday harness review (runbook, #169), the team labels where failed and abandoned jobs first went wrong:

hangar review queue [--since 7d]
hangar review label <job> --seq N --category env --fix env --note "…" [--task]
hangar review status

GET /api/review/queue, POST /api/jobs/{id}/failure-label and GET /api/review/status are the REST equivalents. A job has one failure_label (seq, category, fix, note, candidate_task, labelled_by, at), shown on the job view and the trace (hangar.failure.*). Relabelling replaces it and is audited. Each label is also a label job event in the outbox for flightdeck, and a labelled job's runs are kept until exported.

Outcome classes¶

Every agent turn, best-of-N attempt, experiment trial and job (result.outcome_class, set as it ends) carries an outcome_class beside its outcome, so infrastructure trouble and agent failure no longer look alike:

Records from before this have no class: unknown, never agent. hangar errs towards agent: a turn is infra_error only on a recorded node event (the reconciler's pod_replaced: node repair, scale-down, preemption), the power-down, a control-plane restart, a failed sandbox create or checkpoint restore, or the harness's own error report of a provider error (HTTP 429 after its retries, a 5xx, overloaded_error) on a run that failed. What a tool printed never counts, and a sandbox that died with no such record (a fork bomb, the agent's process killed for memory) stays agent. Jobs aren't retried beyond today's restart and power-down resume; the class is recorded. Turn spans carry it as hangar.outcome.class and hangar.outcome.infra_reason (traces.md).

Settings¶

Tainted jobs¶

A job whose agent read untrusted content (its input was untrusted, or it fetched a page, or called an untrusted MCP server: security/taint.md) delivers its PR as a draft, whatever deliver says, labelled hangar:tainted, and the timeline says so. Landing then needs a reviewer other than the job's own person (landing.md). deliver: branch is unchanged: hangar pushes hangar/<job> after its checks.

Security notes¶

Issue text, comments and service context are untrusted input to the agent. Today's mitigations:

• the repo and environment allowlist for service tokens and GitHub triggers;
• untrusted triggers wait for approval, only trusted people's comments become context, and an untrusted author's text is marked as untrusted in the prompt (triggers.md);
• jobs-only service tokens that can't reach MCP or OAuth;
• secret redaction of everything the agent writes that leaves hangar (summaries, verification output, PR bodies, comments, callbacks);
• pushes only to new hangar/ branches, never forced;
• a prompt that marks context as data;
• CI output, logs and review comments handed to auto-fix turns are untrusted attachments, fenced in the prompt like an outsider's issue text, and only reviewers the job's person or the repo policy trusts start a turn;
• the intake posture (HANGAR_INTAKE_POSTURE, default enforce): a job from GitHub, Jira, Slack or a webhook, or one with an untrusted author or attachment (an auto-fix round), needs the git gateway (otherwise submit refuses it, and the front door posts why) and runs with at least allowlist egress, in a cold-started sandbox when its environment is open. Jobs a person submits over MCP, REST or the CLI are unaffected. enforce is the only value: warn and off were removed after v0.2.0.

Known gap: the callback check resolves the host before sending but doesn't pin the address, so DNS rebinding is not fully blocked. Without the git gateway the agent's sandbox holds a git credential, so restrict HANGAR_GITHUB_REPOS to repos where a mistaken push to a hangar/* branch is acceptable, and keep PR merges human-approved. With HANGAR_GATEWAY_URL set, a job's sandbox has no GitHub token and pushes nothing: its grant is fetch-only, and hangar pushes the commit it checked, after verify, the secret scan and the landing checks (security/git-gateway.md).