feat: add Volcengine Ark Agent Plan provider - #615
Conversation
* fix(ci): let the PR labeler actually write labels * test(ci): pin the labeler to the permissions the API demands
The .codexclaw/ goalplans and ledgers are per-machine agent state. They were committed with 'git add -f' despite the ignore rule, and once tracked the rule stopped applying, so they rode along into main and preview. Untrack them (files stay on disk), drop two .DS_Store files that got in the same way, and add tests/repo-hygiene.test.ts so a forced add fails CI instead of landing silently. Also drop a registry.ts comment pointing at a .codexclaw evidence file that was never committed and cannot be resolved by any reader.
📝 WalkthroughWalkthroughThe PR adds Volcengine Ark Agent Plan provider support with custom response-path routing, filters custom models from disabled providers, updates PR-labeler permissions, expands repository hygiene checks, removes tracked agent artifacts, and bumps the package version. ChangesProvider integration
PR labeler permissions
Repository maintenance
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant ProviderRegistry
participant ProviderDerivation
participant Router
participant Catalog
participant GUI
ProviderRegistry->>ProviderDerivation: register Ark Agent Plan and responsesPath
ProviderDerivation->>Router: propagate provider configuration
Router->>Catalog: expose routed provider and custom models
Catalog->>GUI: provide catalog preset and provider identity
GUI->>GUI: resolve display name and absolute favicon URL
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/pr-labeler.yml:
- Around line 20-27: Reduce the workflow’s pull request permission from write to
read while preserving issues: write in .github/workflows/pr-labeler.yml (lines
20-27). Update the corresponding permission assertion in
.github/scripts/pr-labeler.test.cjs (lines 169-177) to expect the read-only
pull-requests scope.
In `@gui/src/provider-icons.ts`:
- Line 81: Replace the hardcoded “Volcengine Ark Agent Plan” value in the
provider display-name map with the dashboard i18n lookup, and add the
corresponding key to the locale files using the existing provider-label
translation pattern. Keep the provider key “volcengine-ark-agent-plan”
unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 1a87f981-7092-47de-bcba-593b913814ce
⛔ Files ignored due to path filters (2)
devlog/.DS_Storeis excluded by!**/.DS_Storedevlog/_plan/.DS_Storeis excluded by!**/.DS_Store
📒 Files selected for processing (17)
.codexclaw/goalplans/opencodex-4-pabcd-work-phase-wp1-wp2-dev2-go-pr/goalplan.json.codexclaw/goalplans/opencodex-4-pabcd-work-phase-wp1-wp2-dev2-go-pr/ledger.jsonl.codexclaw/goalplans/opencodex-live-unfinished-issues-and-prs-triage/goalplan.json.codexclaw/goalplans/opencodex-live-unfinished-issues-and-prs-triage/ledger.jsonl.github/scripts/pr-labeler.test.cjs.github/workflows/pr-labeler.yml.gitignoregui/src/components/provider-catalog/provider-presets.tsgui/src/provider-icons.tspackage.jsonsrc/codex/catalog/provider-fetch.tssrc/providers/derive.tssrc/providers/registry.tssrc/router.tstests/codex-catalog.test.tstests/provider-registry-parity.test.tstests/repo-hygiene.test.ts
💤 Files with no reviewable changes (4)
- .codexclaw/goalplans/opencodex-live-unfinished-issues-and-prs-triage/goalplan.json
- .codexclaw/goalplans/opencodex-4-pabcd-work-phase-wp1-wp2-dev2-go-pr/ledger.jsonl
- .codexclaw/goalplans/opencodex-live-unfinished-issues-and-prs-triage/ledger.jsonl
- .codexclaw/goalplans/opencodex-4-pabcd-work-phase-wp1-wp2-dev2-go-pr/goalplan.json
| # pulls.get only needs read, but the issues label endpoints are shared with | ||
| # pull requests: adding or removing a label on a PR number is rejected with | ||
| # "Resource not accessible by integration" unless the token also carries | ||
| # pull_requests=write (the API reports `issues=write; pull_requests=write` | ||
| # in x-accepted-github-permissions). Read-only here silently worked while | ||
| # every run happened to be a no-op sync, and failed on the first PR that | ||
| # actually needed a label written. | ||
| pull-requests: write |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Files =="
git ls-files .github/workflows/pr-labeler.yml .github/scripts/pr-labeler.test.cjs
echo
echo "== Workflow excerpt =="
nl -ba .github/workflows/pr-labeler.yml | sed -n '1,120p'
echo
echo "== Test excerpt =="
nl -ba .github/scripts/pr-labeler.test.cjs | sed -n '140,210p'
echo
echo "== Search for related permission/docs references =="
rg -n "pull-requests: write|pull-requests: read|issues: write|label endpoints|Resource not accessible by integration|x-accepted-github-permissions|pr-labeler" .github -SRepository: lidge-jun/opencodex
Length of output: 302
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Workflow excerpt =="
sed -n '1,140p' .github/workflows/pr-labeler.yml
echo
echo "== Test excerpt =="
sed -n '140,220p' .github/scripts/pr-labeler.test.cjsRepository: lidge-jun/opencodex
Length of output: 7064
🌐 Web query:
GitHub Actions permissions issues write pull-requests write labels on pull request number Resource not accessible by integration x-accepted-github-permissions
💡 Result:
The error "Resource not accessible by integration" in GitHub Actions indicates that the GITHUB_TOKEN used by your workflow lacks the necessary permissions to perform the requested API operation [1][2][3]. To resolve this when managing labels or pull requests, ensure your workflow explicitly defines the required permissions in the YAML file [4][5][6]. ### 1. Required Permissions GitHub processes labels via the Issues API [5]. To add or manage labels, you typically need both pull-requests and issues permissions [7][5][8]: yaml permissions: contents: read pull-requests: write issues: write * pull-requests: write: Necessary for actions that modify the pull request itself [7][8]. * issues: write: Necessary specifically for creating new labels or when the action interacts with the labels resource [7][5][8]. ### 2. Common Causes * Forked Repositories: When a workflow is triggered by a pull request from a fork, the GITHUB_TOKEN is granted read-only access by default for security reasons [3][7][8]. * Solution: Switch the event trigger from pull_request to pull_request_target [7][5][8]. This runs the workflow in the context of the base repository, granting it higher permissions [7][8]. Note: Ensure your workflow is secure, as this grants access to repository secrets [8]. * Missing Explicit Permissions: Depending on your repository settings, the default GITHUB_TOKEN might be restricted. Explicitly declaring the permissions block (as shown above) overrides these defaults [4][5]. ### 3. Understanding x-accepted-github-permissions The x-accepted-github-permissions header is a diagnostic tool provided by the GitHub API [9][10]. If you are troubleshooting an API call directly (or through a custom script), this header will be present in the API response [9][11]. It explicitly lists the permissions required to successfully call that specific endpoint [9][12]. You can use this to verify exactly which scope is missing [9]. ### Summary of Best Practices * Grant Least Privilege: Only add the specific permissions needed (e.g., pull-requests: write, issues: write) rather than granting full repository read/write access [6]. * Verify Syntax: Always use the hyphenated form pull-requests in your YAML permissions block; pull_requests (with an underscore) is invalid syntax [13]. * Check Token Source: If using a custom GitHub App or PAT, verify that the token itself has been granted the necessary permissions in its configuration settings [9][10][11].
Citations:
- 1: "HttpError: Resource not accessible by integration" if default Actions permissions are used garrettjoecox/pr-section#1
- 2: https://docs.github.com/en/code-security/reference/code-scanning/troubleshoot-analysis-errors/resource-not-accessible
- 3: Resource not accessible by integration peter-evans/create-pull-request#3236
- 4: Resource not accessible by integration gitleaks/gitleaks#1343
- 5: HttpError: You do not have permission to create labels on this repository actions/labeler#870
- 6: https://github.com/github/docs/blob/main/content/actions/tutorials/authenticate-with-github_token.md
- 7: https://github.com/actions/labeler?tab=readme-ov-file
- 8: https://github.com/marketplace/actions/labeler
- 9: https://github.blog/changelog/2023-08-10-x-accepted-github-permissions-header-for-fine-grained-permission-actors/
- 10: https://docs.github.com/en/rest/authentication/permissions-required-for-fine-grained-personal-access-tokens?apiVersion=2022-11-28
- 11: https://docs.github.com/en/rest/authentication/permissions-required-for-github-apps
- 12: https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/choosing-permissions-for-a-github-app
- 13: "Add labels to an issue" doc refers to
pull_requests:writepermission, but should bepull-requests:writegithub/docs#32167
🌐 Web query:
site:docs.github.com REST API add labels to an issue required permissions pull_requests issues GitHub Apps
💡 Result:
To add labels to an issue or pull request via the GitHub REST API (using the POST /repos/{owner}/{repo}/issues/{issue_number}/labels endpoint), a GitHub App requires write-level repository permissions [1][2]. Specifically, the GitHub App must be granted either of the following repository permissions [2]: 1. Issues: Write [2] 2. Pull requests: Write [2] If the GitHub App is granted write access for either "Issues" or "Pull requests," it will have the necessary authorization to add labels to an issue or pull request [2]. If these permissions are not present, any attempt to add labels will be silently dropped or rejected [3][2].
Citations:
- 1: https://docs.github.com/en/rest/issues/labels
- 2: https://docs.github.com/enterprise-server@3.10/rest/issues/labels
- 3: https://docs.github.com/en/rest/issues/issues
🌐 Web query:
docs.github.com add labels to an issue pull request permissions issues write pull requests write
💡 Result:
To add or manage labels on GitHub issues and pull requests, the required permissions depend on the action being performed and the context (UI interaction versus automation via API/GitHub Actions). For manual operations in the GitHub web interface: - Applying or dismissing existing labels requires triage access to the repository [1]. - Creating, editing, or deleting labels requires write access to the repository [1]. For automation using GitHub Actions or the REST API: - GitHub internally treats pull requests as issues [2][3]. Consequently, API endpoints for managing labels are grouped under the Issues API [2]. - To modify labels in a GitHub Actions workflow, the GITHUB_TOKEN must have explicit write permissions [3]. It is recommended to include the following in your workflow file [3]: permissions: issues: write pull-requests: write Note that while pull-requests: write is often sufficient for applying existing labels to pull requests, adding labels that do not already exist in the repository may require issues: write permissions [3]. When defining these permissions in YAML, ensure you use a hyphen (pull-requests) rather than an underscore, as the latter is a common syntax error [4].
Citations:
- 1: https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels
- 2: https://docs.github.com/en/enterprise-cloud@latest/rest/issues/labels
- 3: HttpError: You do not have permission to create labels on this repository actions/labeler#870
- 4: "Add labels to an issue" doc refers to
pull_requests:writepermission, but should bepull-requests:writegithub/docs#32167
🌐 Web query:
site:docs.github.com/en/rest/issues/labels "Add labels to an issue" permissions "Issues: write" "Pull requests: write"
💡 Result:
To add labels to a GitHub issue, you must have write access to the repository [1]. While specific permission levels can vary based on repository settings, the write access level generally encompasses the ability to manage issue metadata, such as labels [1]. Users with write access can utilize the GitHub REST API to add labels to an issue using the following endpoint: POST /repos/{owner}/{repo}/issues/{issue_number}/labels When using this endpoint, you can provide the labels as an array in the request body [1]. If you have write permissions, you may also replace existing labels or manage them directly through the GitHub web interface, provided your account and repository settings allow for such modifications [1].
Citations:
🌐 Web query:
site:docs.github.com/en/rest/issues/labels "required permissions" "pull requests" "issues"
💡 Result:
On GitHub, pull requests are treated as a type of issue, meaning that shared actions for both features, such as managing assignees, labels, and milestones, are handled through common endpoints [1]. To perform actions on issues and pull requests, users typically require write access to the repository [1]. Specific API requests for these features require identifying the repository owner, the repository name, and the specific issue or pull request number [1]. Information regarding specific permission levels for GitLab was not retrieved.
Citations:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n "`#565`|pull_requests=write|x-accepted-github-permissions|Resource not accessible by integration|issues=write" . -SRepository: lidge-jun/opencodex
Length of output: 157
🌐 Web query:
"POST /repos/{owner}/{repo}/issues/{issue_number}/labels" "pull-requests: write" issues write GitHub App permissions
💡 Result:
To use the GitHub REST API endpoint POST /repos/{owner}/{repo}/issues/{issue_number}/labels, a GitHub App must be granted the "Issues" repository permission with "write" access [1][2][3]. While this endpoint is used to manage labels on both issues and pull requests, the "Issues: write" permission is the mandatory requirement for this specific API call [4]. In the context of GitHub Apps, pull requests are considered a subset of issues, and the "Issues: write" permission covers label management for both [4]. Even if you are performing this operation on a pull request, "Pull requests: write" alone is insufficient; you must explicitly grant "Issues: write" [4]. Summary of requirements: - Permission name: Issues - Access level: Write - Scope: Repository If your GitHub App lacks the "Issues: write" permission, attempts to add labels via this endpoint will result in a 403 Forbidden error [4].
Citations:
- 1: Provide instructions on how to setup an access token release-drafter/release-drafter#1418
- 2: https://docs.github.com/enterprise-server@3.13/rest/issues/labels
- 3: https://help.github.com/en/enterprise-server@3.10/rest/issues/labels
- 4: ci: migrate workflow auth from PAT to GitHub App tokens dyad-sh/dyad#3004
🌐 Web query:
site:docs.github.com/en/rest/issues/labels "GitHub App" "write" "issues" "pull requests"
💡 Result:
To enable a GitHub App to create or manage issues and pull requests, you must configure the appropriate repository permissions in the app settings. For issues, GitHub Apps require the Issues permission, which should be set to Read and write access [1]. This allows the app to perform actions such as creating issues, managing labels, and updating issue details via the REST API [1]. For pull requests, GitHub Apps require the Pull requests permission, also set to Read and write access. Note that GitHub treats pull requests as a type of issue, so shared actions like managing labels, assignees, and milestones for pull requests are handled through the Issues endpoints of the REST API [1]. When performing these actions, you use the REST API endpoints associated with the repository. For example, to add labels to an issue or pull request, you would use the following request [1]: POST /repos/{owner}/{repo}/issues/{issue_number}/labels Ensure your GitHub App has been granted these specific permissions during installation on the target repository.
Citations:
Drop the extra PR write scope
.github/workflows/pr-labeler.yml#L20-L27 only needs pulls.get plus issues.* label calls, so pull-requests: write is broader than necessary here. Keep issues: write, downgrade pull-requests to read, and update .github/scripts/pr-labeler.test.cjs#L169-L177 to assert the read-only scope.
🧰 Tools
🪛 zizmor (1.26.1)
[error] 27-27: overly broad permissions (excessive-permissions): pull-requests: write is overly broad at the workflow level
(excessive-permissions)
[warning] 27-27: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
📍 Affects 2 files
.github/workflows/pr-labeler.yml#L20-L27(this comment).github/scripts/pr-labeler.test.cjs#L169-L177
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/pr-labeler.yml around lines 20 - 27, Reduce the workflow’s
pull request permission from write to read while preserving issues: write in
.github/workflows/pr-labeler.yml (lines 20-27). Update the corresponding
permission assertion in .github/scripts/pr-labeler.test.cjs (lines 169-177) to
expect the read-only pull-requests scope.
Sources: Path instructions, Linters/SAST tools
| alibaba: "Alibaba Coding Plan", | ||
| "alibaba-token-plan": "Alibaba Token Plan", | ||
| "alibaba-token-plan-intl": "Alibaba Token Plan (Intl)", | ||
| "volcengine-ark-agent-plan": "Volcengine Ark Agent Plan", |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Localize the provider display name.
Line 81 adds a user-visible provider label directly to the source map, so it cannot be translated. Add a locale key and resolve the label through the dashboard i18n layer.
As per path instructions, “user-visible strings go through the i18n locale files rather than hardcoded text.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@gui/src/provider-icons.ts` at line 81, Replace the hardcoded “Volcengine Ark
Agent Plan” value in the provider display-name map with the dashboard i18n
lookup, and add the corresponding key to the locale files using the existing
provider-label translation pattern. Keep the provider key
“volcengine-ark-agent-plan” unchanged.
Source: Path instructions
|
Closing as duplicate. This PR also deletes a large amount of unrelated files and changes material that should not be modified in this contribution (version bumps, CI, repo hygiene, historical docs/agent artifacts, etc.). |
3 participants
Summary
/responsespath.responsesPathpropagation and use the official Volcengine favicon URL in the GUI provider icon map.Verification
bun test ./tests/provider-registry-parity.test.ts ./tests/codex-catalog.test.tsbun run typecheckChecklist
Summary by CodeRabbit
New Features
Bug Fixes
Chores
Tests