refined claude beahvior and restricting access - #17
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughThe GitHub Actions workflow configuration is updated to trigger on labeled issues instead of opened/assigned issues. A detailed prompt is added to guide Claude's code generation, including PR creation steps with required commit messages, formatting rules, and feedback handling. Tool allowlisting and progress tracking are explicitly enabled. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Tip You can disable sequence diagrams in the walkthrough.Disable the |
![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 the current code and only fix it if needed.
Inline comments:
In @.github/workflows/claude.yml:
- Around line 55-57: The workflow currently injects "Closes #${{
github.event.issue.number }}" unconditionally which can yield "Closes #" for
PR-related events; update the step that builds the prompt to only append the
"Closes #${{ github.event.issue.number }}" fragment when the
github.event.issue.number value is present (e.g., guard the insertion with a
condition checking github.event.issue.number or github.event_name == 'issues'),
referencing the existing expression `${{ github.event.issue.number }}` so the
output text is only added for issue events.
- Around line 85-88: Update the commented example to use the correct camelCase
CLI flag --allowedTools (replace --allowed-tools) to match the active
claude_args line, and either document in the workflow why claude_args currently
expands permissions beyond local .claude/settings.json (listing the broader
scopes: Git/*, npm/*, Edit/Write/Read/Glob/Grep/LS/WebSearch/WebFetch) or
restrict the claude_args value to mirror the local settings (e.g., limit Git to
status,diff,log,branch,worktree list and npm to npm run:*) so CI permissions are
intentional and consistent with local development.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6f1d3880-3fbd-4067-a00c-f4902f41d0f7
📒 Files selected for processing (1)
.github/workflows/claude.yml
| Closes #${{ github.event.issue.number }}" | ||
| ``` | ||
| Always include a summary of changes AND "Closes #${{ github.event.issue.number }}" in the body. |
There was a problem hiding this comment.
Potential empty value for github.event.issue.number on PR events.
The expression ${{ github.event.issue.number }} is evaluated for all workflow triggers, not just issues. When triggered by pull_request_review or pull_request_review_comment events, this value may be empty, resulting in Closes # in the prompt text.
While Claude should interpret the "WHEN WORKING ON ISSUES" context correctly and not use this for PR work, consider using a conditional expression for clarity:
- Closes #${{ github.event.issue.number }}"
+ Closes #${{ github.event.issue.number || github.event.pull_request.number || 'ISSUE_NUMBER' }}"Alternatively, this may be acceptable as-is since the prompt clearly scopes this instruction to issue work.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Closes #${{ github.event.issue.number }}" | |
| ``` | |
| Always include a summary of changes AND "Closes #${{ github.event.issue.number }}" in the body. | |
| Closes #${{ github.event.issue.number || github.event.pull_request.number || 'ISSUE_NUMBER' }}" |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/claude.yml around lines 55 - 57, The workflow currently
injects "Closes #${{ github.event.issue.number }}" unconditionally which can
yield "Closes #" for PR-related events; update the step that builds the prompt
to only append the "Closes #${{ github.event.issue.number }}" fragment when the
github.event.issue.number value is present (e.g., guard the insertion with a
condition checking github.event.issue.number or github.event_name == 'issues'),
referencing the existing expression `${{ github.event.issue.number }}` so the
output text is only added for issue events.
There was a problem hiding this comment.
@coderabbitai will this cause bug in case of empty issue number?
There was a problem hiding this comment.
@rosh2004, short answer: no, it won't cause a bug — but it does result in slightly malformed prompt text. Here's the breakdown:
-
No workflow failure. GitHub Actions simply substitutes an empty string for
${{ github.event.issue.number }}when the event has no issue (e.g.,pull_request_review). The YAML is still valid and the step runs normally. -
No unintended issue closure. If
Closes #(with no number) somehow ended up in a PR body, GitHub ignores it — it won't close issue#0or any other issue. -
Claude's context scoping helps. The prompt clearly separates "WHEN WORKING ON ISSUES" from "WHEN WORKING ON PR FEEDBACK", so Claude is unlikely to apply the
Closes #instruction during PR events.
The practical risk is cosmetic — the prompt text sent to Claude would read Closes # (incomplete), which is mildly confusing but functionally harmless. The suggestion I raised was more of a defensive clarity improvement than a critical fix:
- Closes #${{ github.event.issue.number }}"
+ Closes #${{ github.event.issue.number || github.event.pull_request.number || 'ISSUE_NUMBER' }}"This ensures the placeholder is always meaningful text regardless of the triggering event. It's optional — your current setup is safe to merge as-is.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
| # claude_args: '--allowed-tools Bash(gh pr:*)' | ||
| # Claude CLI arguments | ||
| claude_args: | | ||
| --allowedTools "Bash(git:*),Bash(gh issue:*),Bash(gh pr:*),Bash(gh repo:*),Bash(npm:*),Bash(npx:*),Edit,Write,Read,Glob,Grep,LS,WebSearch,WebFetch" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
anthropic claude-code-action allowedTools vs allowed-tools CLI argument
💡 Result:
allowedTools (camelCase) is the parameter used in the Claude Agent SDK (TypeScript/Python) to specify tools that Claude can auto-approve without prompting for permission. allowed-tools (kebab-case) does not appear in official documentation as a CLI argument; the correct CLI flag for Claude Code is --allowedTools (camelCase with leading --). In the anthropics/claude-code-action GitHub Action, older versions had direct inputs allowed_tools and disallowed_tools (deprecated). Current v1+ uses claude_args to pass CLI flags like --allowedTools Edit,Read,Write. CLI reference confirms --allowedTools "Read" auto-approves listed tools using permission rule syntax (e.g., "Bash(git *)"). No evidence of --allowed-tools. Some third-party tools may use kebab-case variants, but official Anthropic Claude Code uses camelCase.
Citations:
- 1: https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-permissions
- 2: https://github.com/anthropics/claude-code-action/blob/main/docs/usage.md
- 3: https://docs.anthropic.com/en/docs/claude-code/cli-reference
- 4: https://code.claude.com/docs/en/cli-reference
- 5: https://docs.claude.com/en/docs/claude-code/sdk/sdk-permissions
Fix incorrect CLI argument format in comment and document permission expansion.
The commented example on line 85 uses --allowed-tools (kebab-case), but the correct Claude CLI argument is --allowedTools (camelCase). Update the comment to match the correct syntax used on line 88.
Additionally, the workflow's --allowedTools grants significantly broader permissions than .claude/settings.json:
- Git: Only
status,diff,log,branch,worktree listin settings vs all git commands in workflow - npm: Only
npm run:*in settings vs all npm/npx commands in workflow - File operations & web access: Completely restricted in settings but enabled in workflow (Edit, Write, Read, Glob, Grep, LS, WebSearch, WebFetch)
Document the rationale for this expansion in CI, or restrict permissions to match the local settings if unintended.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/claude.yml around lines 85 - 88, Update the commented
example to use the correct camelCase CLI flag --allowedTools (replace
--allowed-tools) to match the active claude_args line, and either document in
the workflow why claude_args currently expands permissions beyond local
.claude/settings.json (listing the broader scopes: Git/*, npm/*,
Edit/Write/Read/Glob/Grep/LS/WebSearch/WebFetch) or restrict the claude_args
value to mirror the local settings (e.g., limit Git to
status,diff,log,branch,worktree list and npm to npm run:*) so CI permissions are
intentional and consistent with local development.
@coderabbitai will this give any error if the issue number is empty? |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 3689
How GitHub Actions handles itIn GitHub Actions, When is
|
| Trigger | github.event.issue.number |
|---|---|
issues: [labeled] |
✅ Always populated |
issue_comment: [created] |
✅ Populated (issue comments carry the issue object) |
pull_request_review_comment: [created] |
❌ Empty — PR context is at github.event.pull_request.number |
pull_request_review: [submitted] |
❌ Empty — PR context is at github.event.pull_request.number |
Practical impact
For PR-triggered runs, Claude receives Closes # with no number in the prompt. This is misleading, but since your prompt also tells Claude "do NOT create a new PR" for PR feedback, Claude will typically ignore that instruction block anyway. Still, it's cleaner to guard against it.
Recommended fix
You can use a conditional expression to avoid the dangling Closes #:
Closes #${{ github.event.issue.number != '' && github.event.issue.number || github.event.pull_request.number }}Or, more cleanly, move the issue-specific PR creation instruction into a conditional section using an if step or separate the prompt per event type:
prompt: |
**IMPORTANT - WHEN WORKING ON ISSUES:**
After implementing changes, create a pull request:gh pr create --title "Your descriptive title" --body "## Summary
Your summary.
${{ github.event_name == 'issues' && format('Closes #{0}', github.event.issue.number) || '' }}"
This way the Closes # line only appears when the workflow is actually triggered by an issue event.
@claude add this fix |
|
Claude finished @rosh2004's task in 20s —— View job Tasks
ResultUnfortunately, I'm unable to modify files in the What the fix should beHere's the change to make manually in # Replace this:
Closes #${{ github.event.issue.number }}"
# With this (using GitHub Actions expression for conditional):
Closes #${{ github.event_name == 'issues' && github.event.issue.number || github.event_name == 'issue_comment' && github.event.issue.number || '' }}"Or more cleanly, restructure the prompt so the ${{ github.event.issue.number != '' && format('Closes #{0}', github.event.issue.number) || '' }}"This ensures the You can make this change directly in the file and push it yourself. See the FAQ for more info on workflow file limitations. |
1 participant
Summary by CodeRabbit