## Description
This is intended to fix issues with creating new release branches/tags
when the release branch `.github/workflows` directory doesn't match the
`master` branch directory.
The PAT here is owned by our machine user, and has the `contents:write`
and `workflows:write` permissions.
## Description
Removes the `ready-to-implement` default label from the bug report issue template while keeping the `bug` label. Also updates the `triage-issue-local` skill so the triage agent determines whether `ready-to-implement` should be applied based on reproducibility and fix scope.
## Linked Issue
N/A - requested from Slack.
- [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`.
- [ ] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes).
## Screenshots / Videos
N/A - issue template and skill guidance changes only.
## Testing
- `python3` assertion that `.github/ISSUE_TEMPLATE/01_bug_report.yml` now uses only `labels: ["bug"]` and no longer includes `ready-to-implement` in the template metadata.
- `python3` assertion that `.agents/skills/triage-issue-local/SKILL.md` includes the new `ready-to-implement` triage guidance for reproducible, narrow-scope bugs.
- `git diff --check`
## Agent Mode
- [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
_This PR was created by [Oz](https://warp.dev/oz) (running Codex)._
## Summary
Removes two GitHub Actions adapter workflows that delegate to reusable
workflows in `warpdotdev/oz-for-oss` that no longer exist:
- `.github/workflows/respond-to-triaged-issue-comment-local.yml`
- `.github/workflows/comment-on-unready-assigned-issue-local.yml`
Both have been failing on every trigger since 2026-04-30, when
[`warpdotdev/oz-for-oss#400`](https://github.com/warpdotdev/oz-for-oss/pull/400)
deleted the upstream targets as part of migrating to a Vercel webhook
control plane.
## Context
The [`oz-for-oss` maintainer
confirmed](https://github.com/warpdotdev/oz-for-oss/issues/418#issuecomment-4359694437)
the upstream deletions were intentional and asked us to remove the
warp-side adapters rather than restoring upstream. Per-workflow
disposition (her words):
- `respond-to-triaged-issue-comment` — "covered by the issue_comment
hook" of the new Vercel webhook.
- `comment-on-unready-assigned-issue` — "currently being rewired"
upstream.
Root-cause issue:
[`warpdotdev/oz-for-oss#418`](https://github.com/warpdotdev/oz-for-oss/issues/418).
## Verification
Empirical confirmation that the new webhook is live and handling
`@oz-agent` mentions on triaged warp issues — sub-15s response latency
from the `oz-for-oss` bot, well below GHA cold-start times:
- Issue #8642 (2026-05-01 15:24 UTC): `@oz-agent` → bot reply 13s later
- Issue #9576 (2026-04-30 23:33 UTC): `@oz-agent` → bot reply 8s later
- Issue #9688 (2026-04-30 23:33 UTC): `@oz-agent` → bot reply 8s later
Meanwhile every fire of `respond-to-triaged-issue-comment-local.yml`
since 2026-04-30 has logged `failure` (e.g. run
[`25207261218`](https://github.com/warpdotdev/warp/actions/runs/25207261218))
— the GHA path is purely noise.
For `comment-on-unready-assigned-issue` there is a brief coverage gap
until oz-for-oss finishes rewiring the `issues.assigned` event handler.
Failing-and-noisy is worse than absent, so removing now improves signal.
## Scope note
Three additional broken adapters exist for `update-dedupe`,
`update-pr-review`, `update-triage` (weekly scheduled skill-refresh
workflows). Those are intentionally left in place pending confirmation
from `oz-for-oss` on whether the new control plane runs equivalent
scheduled jobs against warp, or whether the replacement scheduled agents
are still upcoming work. Those three have **never** executed for warp
(`gh run list` returns `[]` for each), so leaving them does not affect
any current automation.
## Test plan
- [x] No required status checks affected — verified via repo ruleset
15469325; only `Check CI results` is required.
- [x] No PRs blocked: these workflows trigger on `issue_comment` and
`issues`, never on `pull_request`.
- [x] Empirical webhook coverage verified for
`respond-to-triaged-issue-comment` (see Verification).
- [ ] Reviewer to sanity-check that removing these workflows is
acceptable given the brief coverage gap for
`comment-on-unready-assigned-issue` flagged above.
## Description
**Assumptions**
- The setting schema does not vary between linux builds.
- The separate builds share the same filesystem.
Cache the generated settings schema between Linux builds to avoid
redundant compilations.
During Linux release builds, `prepare_bundled_resources` is invoked
multiple times (once per package format: `.deb`, `.rpm`, AppImage, Arch,
etc.) within the same CI job. Each invocation currently runs `cargo run
--bin generate_settings_schema`, which triggers a full compilation and
execution of the generator binary — even though the output is identical
across formats for the same channel.
This PR adds a `SETTINGS_SCHEMA_CACHE` environment variable to
`prepare_bundled_resources`. When set:
- The **first** invocation generates the schema normally and saves a
copy to the cache path.
- **Subsequent** invocations copy from the cache instead of
regenerating.
The CI workflows (`create_release.yml`) and the Arch Docker action are
updated to set this variable in all Linux packaging jobs.
## Linked Issue
- [ ] The linked issue is labeled `ready-to-spec` or
`ready-to-implement`.
- [ ] Where appropriate, screenshots or a short video of the
implementation are included below (especially for user-visible or UI
changes).
## Testing
- Verified the script logic handles all edge cases: cache not set
(no-op), cache set but file doesn't exist yet (generate + save), cache
set and file exists (copy).
- No user-visible changes; this is a CI-only optimization.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Co-Authored-By: Oz <oz-agent@warp.dev>
## Description
Simplifies the `label_external_contributors` workflow to strictly
determine external contributors by checking if the PR originates from a
fork. Removes the org membership API call (`checkMembershipForUser`) and
the `author_association` fallback logic.
The workflow now only labels a PR as `external-contributor` when
`pr.head.repo.full_name !== pr.base.repo.full_name` (i.e., the PR is
from a fork). Bot PRs continue to be skipped.
## Linked Issue
N/A — requested workflow simplification.
## Testing
Reviewed the workflow YAML for correctness. The logic is
straightforward: fork check + bot exclusion.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
_Conversation:
https://staging.warp.dev/conversation/86ae63f1-b0ae-4f48-a332-381f187ad442_
_Run:
https://oz.staging.warp.dev/runs/019de157-0bfc-77bc-830d-bd1bc98a60b0_
_This PR was generated with [Oz](https://warp.dev/oz)._
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
Adds a new GitHub Actions workflow, `Label External Contributors`, that
runs whenever a pull request is opened and applies the existing
`external-contributor` label when:
* the PR is **not** authored by a bot (`user.type == 'Bot'` or login
ending in `[bot]`), **and**
* either of the following is true (logical OR):
* the author is **not** a member of the `warpdotdev` GitHub
organization, **or**
* the PR head repository is a fork (`pr.head.repo.full_name !=
pr.base.repo.full_name`).
The workflow triggers on `pull_request_target` so the `GITHUB_TOKEN` has
the `pull-requests: write` permission needed to label PRs that come from
forks. The top-level workflow token stays read-only and only the
labeling job widens permissions. The script never checks out the PR's
code — it only reads the event payload and calls a couple of REST
endpoints — so the `pull_request_target` trigger is safe.
Org membership is determined via the GitHub REST membership API. If that
call cannot be performed (for example, when `GITHUB_TOKEN` lacks
org-membership context for a private member), we fall back to the PR's
`author_association` field (`MEMBER` or `OWNER` is treated as internal).
The same heuristic was applied retroactively to all currently-open PRs
in the repo. The retrospective pass evaluated 148 open PRs, skipped 20
bot-authored PRs, labeled 89 external-contributor PRs (all of which were
forks from non-org members), and left 39 internal-author PRs untouched.
## Linked Issue
N/A — direct request from the team Slack channel.
- [x] Where appropriate, screenshots or a short video of the
implementation are included below (especially for user-visible or UI
changes).
## Screenshots / Videos
Not applicable: this PR only adds a CI workflow.
## Testing
* Validated the workflow YAML parses cleanly.
* Exercised the heuristic locally across all 148 currently-open PRs (89
expected to be labeled external, 20 bots skipped, 39 internal — all
matched expectations).
* Verified after retrospectively applying labels that `gh pr list
--state open --label external-contributor` now returns 89 PRs, matching
the dry-run prediction.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
_Conversation:
https://staging.warp.dev/conversation/cf25ce7e-4d2d-4880-a3a3-8c4242f7c0d5_
_Run:
https://oz.staging.warp.dev/runs/019ddf8f-1365-7da4-9c47-75aee57c151c_
_This PR was generated with [Oz](https://warp.dev/oz)._
---------
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
WISOTT
## Linked Issue
<!--
Link the GitHub issue this PR addresses. Before opening this PR, please
confirm:
-->
- [ ] The linked issue is labeled `ready-to-spec` or
`ready-to-implement`.
- [ ] Where appropriate, screenshots or a short video of the
implementation are included below (especially for user-visible or UI
changes).
## Screenshots / Videos
<!-- Attach screenshots or a short video demonstrating the change, where
appropriate. Remove this section if it is not relevant to your PR. -->
## Testing
<!--
How did you test this change? What automated tests did you add? If you
didn't add any new tests, what's your justification for not adding any?
-->
## Agent Mode
- [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
<!--
## Changelog Entries for Stable
The entries below will be used when constructing a soft-copy of the
stable release changelog. Leave blank or remove the lines if no entry in
the stable changelog is needed. Entries should be on the same line,
without the `{{` `}}` brackets. You can use multiple lines, even of the
same type. The valid suffixes are:
* NEW-FEATURE: for new, relatively sizable features. Features listed
here will likely have docs / social media posts / marketing launches
associated with them, so use sparingly.
* IMPROVEMENT: for new functionality of existing features.
* BUG-FIX: for fixes related to known bugs or regressions.
* IMAGE: the image specified by the URL (hosted on GCP) will be added to
Dev & Preview releases. For Stable releases, see the pinned doc in the
#release Slack channel.
* OZ: Oz-related updates. Use `CHANGELOG-OZ`. At most 4 Oz updates are
shown in-app per release.
CHANGELOG-NEW-FEATURE: {{text goes here...}}
CHANGELOG-IMPROVEMENT: {{text goes here...}}
CHANGELOG-BUG-FIX: {{text goes here...}}
CHANGELOG-BUG-FIX: {{more text goes here...}}
CHANGELOG-IMAGE: {{GCP-hosted URL goes here...}}
CHANGELOG-OZ: {{text goes here...}}
-->
## Description
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->
We are looking at making Linux builds more efficient, but for now bump
the linux build timeouts.
## Linked Issue
<!--
Link the GitHub issue this PR addresses. Before opening this PR, please
confirm:
-->
- [ ] The linked issue is labeled `ready-to-spec` or
`ready-to-implement`.
- [ ] Where appropriate, screenshots or a short video of the
implementation are included below (especially for user-visible or UI
changes).
## Screenshots / Videos
<!-- Attach screenshots or a short video demonstrating the change, where
appropriate. Remove this section if it is not relevant to your PR. -->
## Testing
<!--
How did you test this change? What automated tests did you add? If you
didn't add any new tests, what's your justification for not adding any?
-->
## Agent Mode
- [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
<!--
## Changelog Entries for Stable
The entries below will be used when constructing a soft-copy of the
stable release changelog. Leave blank or remove the lines if no entry in
the stable changelog is needed. Entries should be on the same line,
without the `{{` `}}` brackets. You can use multiple lines, even of the
same type. The valid suffixes are:
* NEW-FEATURE: for new, relatively sizable features. Features listed
here will likely have docs / social media posts / marketing launches
associated with them, so use sparingly.
* IMPROVEMENT: for new functionality of existing features.
* BUG-FIX: for fixes related to known bugs or regressions.
* IMAGE: the image specified by the URL (hosted on GCP) will be added to
Dev & Preview releases. For Stable releases, see the pinned doc in the
#release Slack channel.
* OZ: Oz-related updates. Use `CHANGELOG-OZ`. At most 4 Oz updates are
shown in-app per release.
CHANGELOG-NEW-FEATURE: {{text goes here...}}
CHANGELOG-IMPROVEMENT: {{text goes here...}}
CHANGELOG-BUG-FIX: {{text goes here...}}
CHANGELOG-BUG-FIX: {{more text goes here...}}
CHANGELOG-IMAGE: {{GCP-hosted URL goes here...}}
CHANGELOG-OZ: {{text goes here...}}
-->
## Description
Update the default fallback owner for the root `/` pattern in
`.github/STAKEHOLDERS` from the list of FA leads to the
`@warpdotdev/oss-maintainers` team.
## Linked Issue
N/A — small ownership update.
- [ ] The linked issue is labeled `ready-to-spec` or
`ready-to-implement`.
- [ ] Where appropriate, screenshots or a short video of the
implementation are included below (especially for user-visible or UI
changes).
## Screenshots / Videos
N/A — no UI changes.
## Testing
No code changes; this only updates the STAKEHOLDERS file used by the
triage workflow.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
_Conversation:
https://staging.warp.dev/conversation/5d3add1a-47d9-4eb8-9400-a84b51e9f920_
_Run:
https://oz.staging.warp.dev/runs/019ddf7c-4acd-7a1d-8470-5f40af986b2b_
_This PR was generated with [Oz](https://warp.dev/oz)._
Co-authored-by: Oz <oz-agent@warp.dev>
## Summary
- Bumps `actions/setup-node` in
`.github/actions/prepare_environment/action.yml` from v3.9.1 (Nov 2023)
to v6.4.0 (Apr 2026).
- Motivation: the v3 line runs on a Node 16 action runtime, which GitHub
Actions has been deprecating. v4 → Node 20, v5/v6 → Node 24.
- The only input we pass is `node-version: 20.9.0`. None of the inputs
whose semantics changed across majors (`cache`, `always-auth`,
`registry-url`) are used here, so the upgrade is behaviorally inert for
our usage.
## Test plan
- [ ] CI passes on Linux, macOS, and Windows runners that exercise
`prepare_environment`.
- [ ] No new deprecation warnings related to `setup-node` in the action
logs.
## Description
Adds `@vkodithala` as a co-owner on skills, MCP, and long-running shell commands in `.github/STAKEHOLDERS`, so issue and PR triage routes those areas to me as well.
- Skills: `/app/src/ai/skills/`
- MCP: `/app/src/ai/mcp/` and `/crates/mcp/`
- Long-running shell commands: `/app/src/ai/blocklist/action_model/execute/shell_command.rs` (new entry)
## Linked Issue
N/A — focus area / ownership update.
## Testing
Documentation-only change to `.github/STAKEHOLDERS`; no code or tests affected.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Co-Authored-By: Oz <oz-agent@warp.dev>
## Description
Simplifies the public-facing pull request template by removing
internal-only sections and guiding contributors toward the
issue-readiness workflow.
Changes:
- Removed the `Server API dependencies` section and its internal Notion
links.
- Removed the `Changelog Entries for Stable` section (internal release
process).
- Removed the testing-policy Notion link from the `Testing` section.
- Added a `Linked Issue` section with checkboxes asking authors to
confirm:
- The linked issue is labeled `ready-to-spec` or `ready-to-implement`.
- Screenshots or a short video of the implementation are included where
appropriate.
- Added a `Screenshots / Videos` section as a place to attach that
media.
## Testing
Documentation-only change; verified the rendered template via `git
diff`.
_Conversation:
https://staging.warp.dev/conversation/7821ed8c-960f-406d-bec1-485a6c540873_
_Run:
https://oz.staging.warp.dev/runs/019dd545-1271-74cb-81ad-2545e30fb1fc_
_This PR was generated with [Oz](https://warp.dev/oz)._
---------
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
Removes the local-adapter GitHub Actions workflows that delegate to
reusable workflows in `warpdotdev/oz-for-oss`. Those reusable workflows
are being migrated to a Vercel-hosted webhook + cron control plane in
[warpdotdev/oz-for-oss#400](https://github.com/warpdotdev/oz-for-oss/pull/400),
so once the webhook is the active delivery surface for this repo, the
local adapters here are redundant.
The set of removed workflows mirrors what `oz-for-oss#400` actually
deletes from `oz-for-oss/.github/workflows/`. Routing is documented in
`oz-for-oss/lib/routing.py`, which states that the legacy GitHub Actions
adapters are "deleted as routing moves into this module so the webhook
does not race the runner."
Workflows removed (each one matches a delivery surface that the new
webhook now owns or whose upstream reusable workflow is being deleted):
- `.github/workflows/review-pull-request.yml` — PR `opened` /
`ready_for_review` / `review_requested` / `labeled` / `/oz-review`.
- `.github/workflows/enforce-pr-issue-state.yml` — PR `synchronize` /
`edited`.
- `.github/workflows/respond-to-pr-comment-local.yml` — `@oz-agent`
mentions on PRs and review threads.
- `.github/workflows/verify-pr-comment-local.yml` — `/oz-verify` on PRs.
- `.github/workflows/triage-new-issues-local.yml` — `issues.opened`,
`@oz-agent` mention on a non-`triaged` issue, and `needs-info` reporter
replies.
- `.github/workflows/create-spec-from-issue-local.yml` —
`issues.assigned` / `issues.labeled` with `ready-to-spec` and `oz-agent`
assigned, plus `@oz-agent` mention with that lifecycle label.
- `.github/workflows/create-implementation-from-issue-local.yml` —
`issues.assigned` / `issues.labeled` with `ready-to-implement` and
`oz-agent` assigned, plus the `plan-approved` follow-through path.
- `.github/workflows/trigger-implementation-on-plan-approved-local.yml`
— `pull_request_target.labeled` with `plan-approved`; the webhook
handles the spec-approved comment, `ready-to-spec` label removal, and
`create-implementation-from-issue` dispatch inline.
-
`.github/workflows/remove-stale-issue-labels-on-plan-approved-local.yml`
— upstream reusable workflow is deleted in `oz-for-oss#400`; the label
cleanup is handled inline by the webhook's `plan-approved` route.
Workflows intentionally retained (still flow through GitHub Actions, per
`oz-for-oss/lib/routing.py`):
- `respond-to-triaged-issue-comment-local.yml` — `@oz-agent` mentions on
already-`triaged` issues continue to flow through this workflow until it
is migrated in a follow-up.
- `comment-on-unready-assigned-issue-local.yml` — the upstream
`comment-on-unready-assigned-issue` workflow is intentionally kept as
the complement to the webhook's `issues.assigned` route.
- `update-dedupe-local.yml`, `update-pr-review-local.yml`,
`update-triage-local.yml` — cron-driven feedback aggregators that are
not part of the webhook delivery surface.
## Testing
This is a delete-only change to GitHub Actions workflow YAMLs; there is
no code path to test locally. End-to-end verification happens on the
receiving side: once `oz-for-oss#400` is merged and the GitHub App
webhook URL is flipped to the Vercel control plane, the same triggers
(PR opened, `@oz-agent` mention, `/oz-verify`, `issues.assigned`,
`plan-approved` label, etc.) should be delivered through the webhook
rather than these workflows.
## Server API dependencies
N/A — no client/server changes.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Changelog Entries for Stable
<!-- No user-facing change; intentionally no changelog entry. -->
_Conversation:
https://staging.warp.dev/conversation/8de8bc89-f3a0-44eb-94b0-a16a4c5c912c_
_Run:
https://oz.staging.warp.dev/runs/019dda90-b585-70a3-a02b-a9e04f332e13_
_This PR was generated with [Oz](https://warp.dev/oz)._
---------
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
Add vertical tabs, tab configs, worktree, notifications, and rich input
stakeholders from the Warp team side
## Testing
N/A
## Server API dependencies
<!-- You may remove this section if your PR does not have any server
dependencies. -->
- [ ] Is this change necessary to make the client compatible with a
desired [server API breaking
change](https://www.notion.so/warpdev/How-to-safely-introduce-server-API-breaking-changes-0aa805ff5d5d41fd8834f3c95caba0b4?pvs=4#d55ecf8aea3449949d3c33b0e67f6800)?
- [ ] Does this change rely on a [new server
API](https://www.notion.so/warpdev/How-to-add-a-new-full-stack-feature-8412cede405a4ec194b32bdd4b951035?pvs=4#04da1e6a493542d68b3e998c7d339640)?
- [ ] If so, is the use of this API restricted to client channels that
rely on the staging server (e.g. WarpDev)?
- [ ] Is this change enabling the use of a server API on client channels
that rely on the production server (e.g. WarpStable)?
- [ ] If so, has the new server API been stable on production for at
least one server release cycle? See
[here](https://www.notion.so/warpdev/How-to-add-a-new-full-stack-feature-8412cede405a4ec194b32bdd4b951035?pvs=4#73b202f939834b97ab1fbdf7fc82cd53)
for more details.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Changelog Entries for Stable
<!--
The entries below will be used when constructing a soft-copy of the
stable release changelog. Leave blank or remove the lines if no entry in
the stable changelog is needed. Entries should be on the same line,
without the `{{` `}}` brackets. You can use multiple lines, even of the
same type. The valid suffixes are:
* NEW-FEATURE: for new, relatively sizable features. Features listed
here will likely have docs / social media posts / marketing launches
associated with them, so use sparingly.
* IMPROVEMENT: for new functionality of existing features.
* BUG-FIX: for fixes related to known bugs or regressions.
* IMAGE: the image specified by the URL (hosted on GCP) will be added to
Dev & Preview releases. For Stable releases, see the pinned doc in the
#release Slack channel.
* OZ: Oz-related updates. Use `CHANGELOG-OZ`. At most 4 Oz updates are
shown in-app per release.
-->
CHANGELOG-NEW-FEATURE: {{text goes here...}}
CHANGELOG-IMPROVEMENT: {{text goes here...}}
CHANGELOG-BUG-FIX: {{text goes here...}}
CHANGELOG-BUG-FIX: {{more text goes here...}}
CHANGELOG-IMAGE: {{GCP-hosted URL goes here...}}
CHANGELOG-OZ: {{text goes here...}}
---------
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
PRs from external forks have been failing CI because
`google-github-actions/auth` cannot complete OIDC auth: our GCP Workload
Identity Federation provider only trusts the base repository, so the
OIDC token issued for a fork-PR run (which carries the fork's
`repository` claim) is rejected. See [run
#25071797593](https://github.com/warpdotdev/warp/actions/runs/25071797593/job/73455200680?pr=9280)
for an example failure.
The auth is only needed by SSH integration tests, which use `gcloud
compute start-iap-tunnel` to reach a GCP-hosted Ubuntu VM. As a
short-term unblock, this skips the `auth` and `setup-gcloud` steps on
fork-PR runs and filters the SSH-dependent tests out of the test runs
(they all match `_ssh_` in their test names). All other tests continue
to run as before, and SSH integration coverage is unchanged on `master`,
`workflow_dispatch`, `workflow_call`, and same-repo PRs — those tests
still validate post-merge.
A more complete fix (e.g. a `workflow_run`-triggered job that runs SSH
tests in the base repo's context against the fork's SHA) is a possible
follow-up if we decide fork PRs need full SSH coverage.
## Testing
Validated via YAML parse. Will verify behavior on this PR's CI run
(same-repo PR — SSH tests should still run) and on a fork PR before
relying on it.
## Server API dependencies
N/A — CI-only change.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Description
A couple issues that needed fixing:
* Using `--all-features` and `--all-targets` causes us to try to build
the first-party binaries with embedded configuration, which isn't
available from this repository. To unblock CI, we'll only run clippy on
the default feature set for right now.
* Similarly, testing compilation with release configuration was trying
to build the `dev` channel; this switches that over to the `oss`
channel.
## Description
The local `Review Pull Request` workflow in this repo has been failing
on every `pull_request_target` event with `startup_failure` (no jobs
created) for newly opened PRs. Recent runs that hit this:
- https://github.com/warpdotdev/warp/actions/runs/25059789050
- https://github.com/warpdotdev/warp/actions/runs/25059784082
- https://github.com/warpdotdev/warp/actions/runs/25059568488
### Root cause
`.github/workflows/review-pull-request.yml` declares a `focus` input on
its own `workflow_call` interface and forwards it to the upstream
reusable workflow at
`warpdotdev/oz-for-oss/.github/workflows/review-pull-request.yml@main`.
That upstream workflow's `workflow_call` interface no longer declares
`focus` — it was removed in oz-for-oss commit
[`757b052`](https://github.com/warpdotdev/oz-for-oss/commit/757b052) (PR
#393, "feat(review): allow non-collaborator /oz-review and cap at 3 per
PR"). When the local job tries to forward `focus:` in its `with:` block,
GitHub fails workflow validation before any job is created, which
surfaces as `startup_failure`.
### What this PR changes
Drops every reference to `focus` from the local caller so the contract
matches the upstream `workflow_call` again:
- Removes the `focus` input from `workflow_call.inputs`
- Removes `INPUT_FOCUS` from the `resolve` step's `env`
- Removes the `focus = os.environ.get("INPUT_FOCUS", "")` read and the
heredoc-style `focus<<__EOF__` write to `GITHUB_OUTPUT`
- Removes `focus` from the `resolve` job's `outputs:`
- Removes `focus: ${{ needs.resolve.outputs.focus }}` from the
`review_pr` reusable-workflow `with:`
The forwarded inputs are now `pr_number`, `trigger_source`, `requester`,
and `comment_id`, matching the upstream interface.
### Note on `enforce-pr-issue-state.yml`
While debugging, I confirmed `enforce-pr-issue-state.yml` is
`workflow_call`-only and is not invoked anywhere in this repo (it has
zero historical runs), unlike in `oz-for-oss` where `pr-hooks.yml`
orchestrates enforcement before reviews. That gap is independent of this
fix — `review-pull-request.yml` here listens directly to
`pull_request_target` and does not depend on enforcement output. If we
want enforcement to gate PR reviews on this repo too, that's a follow-up
(either add a `pr-hooks.yml` orchestrator or wire
`enforce-pr-issue-state.yml` to listen to `pull_request_target` directly
and have `review-pull-request.yml` `needs:` it).
## Testing
- `python3 -c "import yaml; yaml.safe_load(...)"` on the modified
workflow to confirm the YAML still parses.
- Diff-checked that the local `with:` block matches the inputs declared
by the upstream `workflow_call` at
`warpdotdev/oz-for-oss/.github/workflows/review-pull-request.yml@main`.
- After this merges, the next `pull_request_target` event on a non-draft
PR should produce a `Review Pull Request` run that actually creates the
`resolve` and `review_pr` jobs instead of failing at startup.
## Server API dependencies
N/A — CI workflow change only.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
_Conversation:
https://staging.warp.dev/conversation/dd8c9b9a-256b-4c79-abc2-cb513f7236b5_
## Changelog Entries for Stable
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
The reusable workflows under
[`warpdotdev/oz-for-oss`](https://github.com/warpdotdev/oz-for-oss/tree/main/.github/workflows)
declare their Warp API key secret as `OSS_WARP_API_KEY`, but the local
caller workflows in this repo were forwarding it as `WARP_API_KEY`.
Because the name being passed didn't match the name declared by
`workflow_call`, the required secret was effectively missing and an
undeclared secret was being passed instead, which caused
`startup_failure` on every invocation.
Example failure:
https://github.com/warpdotdev/warp/actions/runs/25058665906 (Triage New
Issues (Local), `startup_failure`).
This PR renames the forwarded secret to `OSS_WARP_API_KEY:` in all local
adapter workflows so the names match what the reusable workflows
declare. The underlying secret value is still pulled from
`secrets.OSS_WARP_API_KEY` in this repo, so no repo secret changes are
needed.
Affected workflows:
- `.github/workflows/create-implementation-from-issue-local.yml`
- `.github/workflows/create-spec-from-issue-local.yml`
- `.github/workflows/enforce-pr-issue-state.yml`
- `.github/workflows/respond-to-pr-comment-local.yml`
- `.github/workflows/respond-to-triaged-issue-comment-local.yml`
- `.github/workflows/review-pull-request.yml`
- `.github/workflows/triage-new-issues-local.yml`
- `.github/workflows/trigger-implementation-on-plan-approved-local.yml`
- `.github/workflows/update-dedupe-local.yml`
- `.github/workflows/update-pr-review-local.yml`
- `.github/workflows/update-triage-local.yml`
- `.github/workflows/verify-pr-comment-local.yml`
## Testing
Manual review of the rename. After merge, re-run the failing `Triage New
Issues (Local)` workflow to confirm it no longer hits `startup_failure`
due to a missing required secret.
## Server API dependencies
N/A — CI workflow change only.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
_Conversation:
https://staging.warp.dev/conversation/fbace74a-9da2-445f-8486-e5a5907dce57_
_Run:
https://oz.staging.warp.dev/runs/019dd47c-42e0-7072-8206-e6be4df5cde7_
_This PR was generated with [Oz](https://warp.dev/oz)._
Co-authored-by: Oz Agent <oz-agent@warp.dev>
