---
title: "Run intents, additional repositories, and Venice search"
date: "2026-08-21"
---

## Version-backed run creation

Fabro's canonical `POST /api/v1/runs` endpoint now also accepts a strict
`RunIntent` body that creates a submitted run from an immutable workflow
version, a named server environment, and an explicit public GitHub repository
target. Creation remains separate from execution; call the existing start
endpoint when the run should begin.

Git targets require a branch and may pin a full commit SHA. Fabro normalizes a
submitted SHA to lowercase and uses that exact commit during sandbox setup,
without resolving it during admission or falling back to a newer branch HEAD.
The environment ID defaults to `default`; this first target slice supports
clone-enabled Docker and Daytona environments.

Existing manifest callers continue to work unchanged and can migrate
independently. Intent runs do not consume repository `project.toml` settings:
the selected server environment owns provider, working directory, and image,
while workflow versions may still overlay resources, network, lifecycle,
labels, and environment variables. Project metadata therefore no longer adds
run labels on this path, and repository-wide settings must move into workflow
versions or server defaults before a caller migrates.

## One token for the whole repository set

A run can now declare additional GitHub repositories that its stages may access through the managed `GITHUB_TOKEN`:

```toml
[run.integrations.github]
additional_repositories = ["fabro-sh/keystone"]
permissions = { contents = "read" }
```

The run origin stays implicit, and Fabro mints one installation token scoped to the origin plus every declared repository with the shared permission map. Inside stages, `gh` commands, raw GitHub API calls, plain Git over HTTPS, and the common SSH URL spellings (`git@github.com:owner/repo` and `ssh://git@github.com/owner/repo`) all work against the declared set — the SSH forms are transparently rewritten to authenticated HTTPS with no secret placed in Git configuration.

Every repository must share one owner and be reachable by the origin's GitHub App installation. Preflight resolves each repository's installation, mints the scoped token once, and probes every repository with `git ls-remote`, naming the exact repository when something is not accessible; run initialization enforces the same checks. A declared-but-inaccessible repository fails the run before its first stage.

Declaring additional repositories requires `contents = "read"` or `contents = "write"`. With `contents = "write"`, any stage can push to any declared repository — declare the smallest set and weakest permissions that work. See [Additional repositories](/integrations/github#additional-repositories) for details, including layering rules and `GH_TOKEN` precedence.

## Venice search backend for `web_search`

The built-in `web_search` tool now supports Venice as an automatic alternative to direct Brave Search. Fabro uses `BRAVE_SEARCH_API_KEY` when present. Otherwise it uses `VENICE_API_KEY` with Venice's Brave search engine. If neither key is present, the tool is not registered. Failed calls do not fall back between providers.

See [Venice Search](/integrations/venice-search) and [Brave Search](/integrations/brave-search).

## More

<Accordion title="Workflows">
- Docker and Daytona clones now default to 100 commits; set `[run.clone] depth = 0` for full history or a smaller positive depth for a shallower clone
</Accordion>

<Accordion title="Fixes">
- Runs now fail if durable event persistence is lost instead of continuing with incomplete history
- Venice model responses now include provider-reported top-level costs in billing totals
- Daytona post-clone setup now has a bounded wait
</Accordion>

<Accordion title="Improvements">
- Large context values moved out of agent prompt preambles now render as concise file references with bounded previews
- Added the Venice built-in model provider catalog and integration guide
</Accordion>
