@ad-m-ss we probably won't have the branch creation behavior by default, other than when you @-mention Claude in an issue. We plan to provide sample prompts for people to start with.

I use Claude, for example, to fix migration issues. My recent comment on the pull request:

@claude review failing tests in CI, and fix them.

Also on issues:

@claude implement it

Does this mean I'll have to write "create a new branch, fix, commit, push" instead of just "fix" or "implement"?

For the basic case of tagging Claude, we'll continue providing a default behavior that works like today.

Typo! Fixed.

The main benefit of the outer action in that case will be that it uses the Claude github app, whereas the base one does not. Continuing conversations is something we may look into!

Does that mean agent mode won't be able to use a custom app/token for authentication?

Cross-repo is something we'd like to support, but isn't part of the v1 update. We're aware of the security benefits of staying single-repo, so when we do offer it as a feature, it will be opt-in.

Thank you very much for the clear and quick response

@K3UL Just FYI, now you can handle multiple repos via claude-code-base-action.

Check out multiple repositories into a single workspace directory, then run claude-code-base-action with the CLAUDE_WORKING_DIR env variable set to that directory. This allows Claude Code to work across all repositories.

Check out --model: https://docs.anthropic.com/en/docs/claude-code/cli-reference#cli-flags

I've seen these docs before, what is not well-explained is whether or not we have to use a different identifier if we're using (for example) Bedrock (instead of Anthropic directly, or Vertex):

claude --model claude-sonnet-4-20250514

So I'm assuming what this means for Bedrock users is that we'd instead use claude --model us.anthropic.claude-3-7-sonnet-20250219-v1:0, and it'd work in-place?

Great question!

So override_prompt currently just replaces the entirety of Claude's prompt (you can see more below)

In v1, if you provide a prompt at all through prompt it'll automatically override Claude's entire prompt. This should preserve your desired functionality.

Separately, #437 does say the changes are upcoming and is also reflected in this discussion; but if it's still confusing I can change it! Thanks for the feedback!

You should be able to use subagents already, are you facing issues there?

Yes, I was trying to add them in .claude/agents and ask to use them in the prompt, but instead it uses Task and something like this: "command": "which jira-agent",
| "description": "Check if jira-agent command exists"

I found the reason for my issue. I was using an old version of the action. I switched to the newer one and it worked. Sorry for the misleading.

I think this could work but it would require you to create an effective prompt for this. In general though, if you can get something working with claude -p locally, it should work in v1.

Tested with the v1-dev branch. Works with a decent prompt.

@csellis without promising any specific date, I think we're expecting to have something ready by end of this month (though that's subject to change).

That said, the v1-dev branch is already available (with an open PR here), and we've been using it heavily internally for some time now.

How does one try it? Do you have an example of a review workflow with a custom prompt that would uses variables like

<changed_files>
    $CHANGED_FILES
 </changed_files>

Initial attempt at getting this to work was unsuccessful!

@julien-lottie, you should be to use custom prompts already with v1-dev. Like so: https://github.com/anthropics/claude-code-action/blob/f5c5d2d6771836c113bf6d3188f0bcb7708254dd/examples/auto-fix-ci/auto-fix-ci.yml#L85C11-L92C49

Thanks. One feedback based on trying it.
If you want to trigger your review with @claude review this, you are in agent mode and mcp__github_inline_comment__create_inline_comment doesn't seem available since it's only added by the review mode. It would be great if you could make this available 🙏

In general I'm unclear why there is a distinction between those 2 modes if you are going to provide your own prompt. It feels like all the tools should be available and you should be able to enable / disable the one you wish. What am I missing?

Thanks for sharing @vibhor1997a, as we ramp up SDK support, we'd want to ensure we're aligned with whatever updates the SDK comes with, without having to modify the github action. We'll make sure to have some docs referencing the above in the github action, and also guiding users to the SDK docs to make it easier to use

Yes, and you can also click the workflow itself in order to do get a result of the run

Yep!

We can now ask claude to re-run CI if it'd need. Now it can go through and identify failed runs, then re-run those automatically (with fixes). This would require it's own workflow file though

Ah, so it needs the ability to trigger workflow runs. I don't really want that - I only want Claude for PR review, and to tag it when replying to the assessment. It is purely readonly for me - any write actions will be done locally.

Writing workflows is necessary for making changes to .github/workflows, which is something the current action fails at. This has been a common user request.

To add to @ashwin-ant 's answer, GitHub has additional scopes required for writing to .github/workflows as an additional later of security, as apps that can do that can potentially run unreviewed code (even in PR with the appropriate triggers) against your code and potentially private infrastructure.

In effect, contents:write and workflows: write are both required to grant write access to the full repo.

But what if a user doesn't want to leverage those features? I don't think that workflows: write should be required to use this action. If we use workflows for deploying to production, that means that in effect, now Claude can deploy to production on its own which is massive security issue.

Hm, could you please iterate more on your usecase? tag mode is mainly to @.Claude to respond to issues. Tag mode's prompt generation is aligned towards solving issues and PRs, maybe you can try constructing a prompt that would be better suited for your usecase? Happy to provide a deeper response once I get some context

This should be possible if you allow it to use tools for doing so, either an MCP server or just gh commands. It's just that our default configs don't do it, so it requires some customization. We could provide an example workflow of how to achieve this.

In my workflow we gave it a custom GitHub app with appropriate permissions to write to the repo, then generate the token (make sure to gh auth setup-git and set git config) and explicitly instruct it like:

You have been given a gh tool, a GH_TOKEN in your environment which grants you access to all repos in the xxx org, and a preauthenticated git client. Despite previous instruction that you cannot, it is CRITICAL that all of your changes be appropriately committed, pushed to the remote, and a PR opened for review. FAILURE TO OPEN PULL REQUESTS IS A FAILURE TO COMPLETE THE TASK. Your environment is ephemeral and all changes not pushed to the remote will be lost. A pull request is crucial for soliciting feedback, testing via CI workflows (which you also have access to), and obtaining approval to integrate your code into the base branch.

Yeah, understood. One thing that may be useful: Since the prompt in v1 can just be a slash command, you could keep your prompt in the .claude/commands directory and just reference it as a slash command in the workflow file. This would make it easier to iterate on. You can even specify allowed tools in the slash command markdown file: https://docs.anthropic.com/en/docs/claude-code/slash-commands#custom-slash-commands

the current workflow we have makes little to no sense to keep in .claude/commands (even tho i understand your idea). We've been building a workflow which corrects the PR title based on the PR diff ; as we enforce squash merge, the PR title gets into the git log and it's of very good value to have meaningful PR titles. maybe it could be a slash command but since the workflow is tied to using gh and we don't want to enforce gh in every workstation, details of this workflow should remain endemic to CI (= not in a usable slash command)