T3 Code Nightly COPR

RPM packages for the x86_64 T3 Code desktop nightly:

• t3code-nightly repackages the official upstream AppImage. It does not build T3 Code from source.
• t3code-prs-nightly compiles the same nightly from source with patches/prs/ applied: Command Code as a full provider (driver, CommandCodeAdapterV2, NDJSON protocol, model catalog, snapshot, text generation, contracts schema, settings-UI definition) and Oh My Pi as a bundled ACP Registry entry. Since upstream merged the orchestrator rewrite (pingdotgg/t3code#2829) into main on 2026-10-02, main carries the v2 orchestrator, the Pi coding agent driver, and the generic ACP provider registry, so this is a from-source build of the same revision the plain nightly repackages plus those two integrations. The v2- prefix was dropped once the orchestrator merge retired the clean t3code-v2-nightly flavor and made the prefix meaningless; the two names it replaces (t3code-v2-prs-nightly and t3code-v2-nightly) are obsoleted, so dnf upgrade moves their users over.

Neither integration is upstream yet, as of 2026-10-04: no open pull request carries Command Code or Oh My Pi, the provider PRs #10861 and #11973 were closed without merging, and the official ACP Registry has no Oh My Pi entry (registry PRs #613, #572, and #502 are still open). The flavor therefore carries them as local patches rather than layering pull requests, which its earlier incarnation did, and the name is kept from that incarnation.

Upstream publishes no AppImage derived from this repository's patches, so the layered flavor is compiled from source in GitHub Actions and packaged the same way afterwards. Local patches from patches/<flavor>/ are applied after the upstream tree is checked out; see Local patches.

Both packages build the upstream nightly tag (scripts/resolve-latest-nightly.sh picks the newest -nightly. prerelease; -preview. maintainer builds are ignored). The layered flavor rebuilds only when its inputs changed, so a nightly tag it has already packaged is skipped.

The layered package installs the same files as t3code-nightly and carries Obsoletes: t3code-nightly plus a higher release, so it replaces the plain nightly instead of conflicting with it. It also obsoletes the retired t3code-cmd-nightly and t3code-v2-nightly names and its own t3code-v2-prs-nightly predecessor. The layered flavor does not obsolete the plain nightly: they are alternatives on the same paths, so switching between them is an explicit dnf swap.

COPR setup

1. Create a COPR project called t3code-nightly (or choose another name). Enable the Fedora chroots you intend to support.

2. In the GitHub repository, add these Actions secrets:

   • COPR_CONFIG: the complete ~/.config/copr file generated by copr-cli. Keep it as a multi-line secret.
   • COPR_PROJECT: the COPR project identifier, for example your-copr-user/t3code-nightly.

3. Enable Actions. Two workflows publish here, staggered so they do not build at the same minute:

   • Publish T3 Code nightly to COPR (:17) checks the official prereleases and submits the t3code-nightly source RPM only when it sees a new tag. It records the successful submission in packaging/last-built-tag.
   • Build T3 Code nightly with Command Code and Oh My Pi (:33) builds the same tag with patches/prs/ applied and submits the t3code-prs-nightly source RPM, recording packaging/prs/last-built-key.

Only the plain nightly exists for every upstream tag from the moment it is published; the layered flavor rebuilds only when its inputs changed, so a nightly tag it has already packaged is skipped.

Use Run workflow with force when a COPR rebuild of the same inputs is needed. The normal CI workflow validates the RPM specs and checks the patches still apply to the newest nightly on pushes and pull requests but never accesses COPR credentials.

Local patches

patches/<flavor>/*.patch are applied after the upstream tree is checked out and before the AppImage is built, and the build key includes a digest of them, so editing a patch triggers a rebuild. Each patch must apply cleanly to the layered tree; if upstream changes the file it touches, the build fails instead of quietly shipping something else.

The prs flavor carries these as local patches, not pull requests, because no upstream pull request carries them: the one that added the Command Code provider (#10861, "on current main") was closed without merging, the same happened to the Oh My Pi driver (#11973), and the Oh My Pi ACP Registry entry is still pending. The prs name is kept from the flavor that layered those pull requests before the orchestrator merge made that impossible.

Patch	Why
patches/prs/0001-acp-bundled-oh-my-pi-entry.patch	Oh My Pi is ACP-native but its official ACP Registry entry is still pending, so the Registry flow cannot offer it. The patch ships the entry with the app (bundledAcpAgents.ts) and merges bundled entries behind fetched ones, so the official listing takes over automatically once it is published.
patches/prs/0002-command-code-provider.patch	The Command Code provider against the orchestration interfaces main carries since the #2829 merge: driver, CommandCodeAdapterV2, NDJSON protocol, model catalog, snapshot, text generation, contracts schema, and the settings-UI definition. Mid-turn sends are steered into the running turn by the v2 orchestrator (supportsActiveSteering), with the queueing implemented in the adapter because the CLI takes one prompt per process.

A patch is not upstreamed here: once an equivalent change carries the fix, delete the patch file and its row.

Local build

On Fedora:

sudo dnf install rpm-build rpmdevtools curl
./scripts/build-srpm.sh v0.0.29-nightly.20260712.791

The source RPM is written to rpmbuild/SRPMS/.

The layered flavor repackages AppImages that only CI builds, so it needs one on disk:

./scripts/build-layered-srpm.sh prs v0.0.29-nightly.20260712.791 \
  T3-Code-0.0.29-nightly.20260712.791-x86_64.AppImage

That AppImage has to come from the tree with the patches in patches/ applied; CI is the only place that builds it, so the local path is mostly for packaging an AppImage you already have.

Installing a layered build over the plain nightly

The packages own the same files, so install them as a swap rather than alongside each other:

sudo dnf swap t3code-nightly t3code-prs-nightly # source build + ported providers

The layered package also obsoletes t3code-nightly, the retired t3code-cmd-nightly and t3code-v2-nightly, and its own t3code-v2-prs-nightly predecessor, so a plain sudo dnf upgrade reaches the same result as the swap, including for users of the retired v2 names. Switching back to the plain nightly is explicit, because the layered package does not obsolete it.

Notes

These are unofficial packages. T3 Code is distributed under the MIT license. t3code-nightly ships the upstream AppImage unchanged; the layered flavor ships an AppImage built from upstream sources plus the local patches named above. Since upstream's orchestrator merge made the v2- prefix meaningless and a clean from-source rebuild redundant, the former t3code-v2-nightly and t3code-v2-prs-nightly flavors became t3code-prs-nightly, which obsoletes both retired names.