When a run declares additional repositories, preflight now proves the
whole effective set works instead of treating a minted token as proof:
- It constructs the same validated `GitHubRepositoryAccess` used by
runtime initialization, so the two paths cannot disagree.
- In App mode it first resolves every repository's installation with
the App JWT and requires one shared installation ID, naming any
repository the App cannot see before the mint; then it mints the one
scoped token, failing with the raw error on rejection.
- Every effective repository gets a non-interactive
`git ls-remote <url> HEAD` probe through a shared helper that keeps
the token out of the URL, argv, and errors (a credential helper reads
GITHUB_TOKEN from the child environment), retries auth-shaped
failures with the same token to cover replication lag (classified
via fabro_sandbox::classify_failure), and reports one check per
repository in deterministic primary-first order under bounded
concurrency.
- A resolved run environment that defines GH_TOKEN produces a warning
(gh prefers it over the managed token) without failing preflight.
- With no additional repositories declared, the primary-only mint
check is byte-for-byte unchanged.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Carry the resolved GitHub integration (permissions plus declared
additional repositories) as one value from run materialization into
workflow startup, and make the sandbox environment reach every declared
repository through the single managed GITHUB_TOKEN.
- `StartServices.github_permissions` becomes
`github_integration: ResolvedGithubIntegration`; CLI and server
workers build it with `resolve_integration()` after interpolation and
pass it through `SandboxEnvSpec` as one unit.
- `build_sandbox_env` constructs the validated
`GitHubRepositoryAccess` and scopes the App token source to the whole
effective set. Missing credentials or a missing origin are hard
initialization errors when additional repositories are declared;
legacy permissions-only configuration keeps its best-effort behavior.
- When additional repositories are declared, initialization eagerly
resolves each repository's App installation (naming any repository
the App cannot see) and the token itself, so an inaccessible declared
repository fails before the first workflow stage.
- A new `git_bridge` module injects secret-free `GIT_CONFIG_*` entries
into the stage environment: a github.com credential helper that reads
`$GITHUB_TOKEN` at invocation time, per-repository SSH-to-HTTPS
`insteadOf` rewrites, and `GIT_TERMINAL_PROMPT=0`. Entries append
after a valid user-provided Git config overlay and fail clearly on a
malformed one. Contract tests drive the installed git binary against
local fixtures for the rewrite, credential, prefix-collision, and
overlay-preservation behaviors.
- The long-running ACP notice now says all declared repository access
expires together.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Add `GitHubRepositoryAccess`, the secret-free validated value describing a
run's effective GitHub repository set: the primary origin repository plus
the declared additional repositories with the shared permission map.
- The constructor normalizes HTTPS and both SSH origin spellings to one
primary slug, rejects a missing or non-GitHub origin when additional
repositories are declared, rejects primary duplication and cross-owner
additional repositories, and re-checks that interpolated permissions
carry `contents = "read"|"write"` — exposing targets in deterministic
primary-first order.
- `resolve_shared_installation` resolves every target's App installation
with the App JWT and requires one shared installation ID, naming the
repository the App cannot see before any mint.
- The installation-token mint now accepts a repository-name list; the
single-repository entry points delegate to it, and the request body
lists every projected name with the shared permissions.
- `InstallationTokenSource::for_access` builds a source over the access
value; caching, refresh margin, and single-flight are unchanged.
- The scripted `MockHttpClient` and test RSA key move to a shared
crate-internal `tests_mock` module.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Add `additional_repositories` to `[run.integrations.github]`: a list of
full `owner/repository` slugs, beyond the implicit run origin, that the
minted GITHUB_TOKEN must cover.
- `GitHubRepositorySlug` gains FromStr, Display, string serde, and
case-insensitive Eq/Ord/Hash identity while preserving the submitted
spelling for display and serialization.
- The config layer keeps raw strings; the higher-precedence list
replaces the lower one wholesale, with `[]` as an explicit clear,
resolving independently from the `permissions` map.
- Resolution validates each entry with indexed error paths: slug
grammar, case-insensitive duplicates, one shared owner, the
499-repository cap, and a required `contents = "read"|"write"`
permission (templated values are re-checked at the runtime boundary).
- `RunIntegrationsGithubSettings` resolves permissions and repositories
together through `resolve_integration()` so consumers cannot pick up
one without the other; the field is omitted from serialization when
empty, keeping single-repository settings byte-identical.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Fabro can mint a scoped sandbox GITHUB_TOKEN via
[run.integrations.github.permissions], but apps registered through the
manifest flow could not grant packages = "read" because the manifest
never requested it. Add Packages (read-only) so freshly registered apps
can download private GitHub Packages (for example npm registry
dependencies) inside sandboxes, mirroring how GitHub Actions workflows
use their built-in GITHUB_TOKEN for registry reads.
Existing apps still need the permission added manually in the app's
settings, as the docs already describe.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Replace the public stored-token row with an initial-token input that carries only token-specific facts. Bind the token to the session and initialize it as unused inside AuthSessionStore so callers cannot create mismatched session/token rows.
Delete the owning auth session inside the refresh-token rotation transaction when a spent token is replayed. Return the replay outcome only after the revocation commits, and propagate database failures without claiming the chain was revoked.
The lineage field's `skip_serializing_if` behavior was asserted five times
across three crates. Keep the two assertions in fabro-types, which owns the
attribute, and drop the duplicates:
- Delete `run_created_omits_absent_workflow_version_id` from event/convert.rs,
a copy of the test above it that re-checked another crate's serde attribute.
convert.rs's own responsibility is covered by the existing field assertion.
- Delete `legacy_create_input_persists_without_workflow_version_id`, which ran
the full create() pipeline to prove a hardcoded `None` literal is `None`.
`CreateRunInput` has no such field, so no input could change the result.
- Fold `run_spec_omits_absent_workflow_version_id` into the adjacent legacy-spec
test, which already holds an all-`None` record.
- Drop the off-topic spec re-serialization from run_state.rs's retried_from test.
Add `test_support::test_workflow_version_id()` alongside `test_run_provenance()`
and use it everywhere, replacing eight copies of the same magic seed across five
crates plus two assertion sites that recomputed the hash inline. This also
subsumes retry.rs's private helper of the same shape.
Revert the `run_spec_json` parameterization in the projection round-trip test:
`RunProjection` is a `with_replacement` alias for the canonical type, so the
`Some` and `None` call sites exercise identical code.
Have the two run.created literals that mirror a `RunSpec` read the spec's
lineage field instead of hardcoding `None`, so the mirrors stay accurate once a
producer populates it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The release push raced any commit that landed on main while the release
smoke ran (~15 minutes): git push was rejected as non-fast-forward and
the whole release failed, as seen on the v0.332.0-nightly.1 attempt.
Worse, the push was not atomic — if the tag ref had been accepted while
the main ref was rejected, the release would have shipped from an
orphan commit and main would never have received the version bump.
Make the push atomic (both refs or neither) and add a bounded rescue
loop: on rejection, drop the bump commit and tag this run created,
fast-forward onto the updated origin/main, recompute the version
against freshly fetched tags, and rebuild the bump commit on the new
tip. The fast-forward uses --ff-only so a genuinely diverged local main
(unpushed commits) fails loudly instead of being reset away.
The retried tag can include commits the smoke did not test; those
commits passed CI to land on main, and the Release workflow re-runs the
full test suite on the tagged commit before publishing anything.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The release, docker, and Homebrew jobs ran on ubuntu-latest, which
migrates across Ubuntu major versions on GitHub's schedule. Pin to
ubuntu-24.04, the image ubuntu-latest resolved to in the last green
release run, matching the explicit runner labels used elsewhere.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
setup-bun installed the latest Bun at run time, so every job floated to
new Bun releases the day they shipped. Bun bundles the SPA embedded in
release binaries, so an unvetted Bun release could break or silently
change shipped artifacts. Pin to 1.3.14, the version the last green
nightly used, and hold off on the day-old 1.4.0 until it has soaked.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Rust 1.98.0 (released 2026-08-20) passes --fix-cortex-a53-843419 to the
linker for aarch64-unknown-linux-musl, which the zig cc wrapper used by
cargo-zigbuild rejects, breaking the release build for that target. Pin
all workflows that installed unpinned stable to 1.97.1 until the zig
toolchain handles the new flag. The nightly-2026-04-14 fmt/clippy
toolchains are unchanged.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
RunId is a ULID, so its embedded timestamp is truncated to whole
milliseconds, while Variable.updated_at comes from Utc::now() with
sub-millisecond precision. When the variable write and the run creation
landed in the same millisecond, the run id compared as earlier and the
assertion failed. Truncate the variable timestamp to milliseconds so
both sides use the same precision.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sandbox exec logs previously required command_len fingerprinting to tell a
push from a credential refresh or a checkpoint commit. The shared git
helpers now instrument their futures with a git_op span, so Daytona's and
Docker's `exec_command: entered` lines inherit the operation label and the
log renders as `git_op{op=push}: exec_command: entered timeout_ms=...`.
Ops: push (git_push_via_exec), refresh-credentials (both providers'
refresh_push_credentials), checkpoint-commit (checked_git_checkpoint),
fetch (fetch_source_run_ref), and metadata-push (the run-metadata snapshot
write). Spans are attached with #[tracing::instrument] — attached to the
future, never an entered() guard held across an await — so they follow the
task across worker threads. No trait or signature changes.
Plan: .ai/plans/git-push-token-resilience.md (PR 3: item 10).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
