Claude Code Internal Tooling for Software Teams: Issues to Draft PRs

What counts as Claude Code internal tooling, and what does not?

Two things get called by this name, and they need different care.

• Developers using Claude Code interactively in their terminal or editor. This is personal tooling, governed by team conventions and the permissions each developer approves.
• Claude Code running unattended on a trigger, such as a labelled issue or a nightly job. This is internal tooling in the sense of this page: a repeatable job with fixed instructions, limited permissions and a defined output.

Anthropic's documentation says the same agent loop and tools are available in non-interactive form through claude -p, and as Python and TypeScript packages for fuller control. This page concentrates on the unattended kind, because that is where limits matter most. Our agentic AI and Claude Code development page describes the wider service, and the post on Claude Code for business automation covers non-engineering uses.

Illustrative scenario: a bug report becomes a draft pull request

An invented example, not a client result. A product team keeps its code on GitHub. A support engineer labels an issue claude-draft after confirming it describes a real, reproducible bug. The pipeline then runs in four gates.

1. Gate one: trigger and identity.
   • Input: the issue text and the label event.
   • Check: the person who applied the label has write access. Anthropic's GitHub Actions documentation says the action checks that a triggering user has write access, and rejects bot actors unless they are listed.
2. Gate two: reading.
   • The agent reads the issue, the instructions file and the relevant source directories on a fresh checkout.
   • It runs the existing tests to see a baseline.
3. Gate three: working under limits.
   • Tools allowed: read and edit files, run the test and lint commands you listed, nothing else.
   • It writes a failing test that reproduces the bug, then a minimal fix, then re-runs the tests.
   • A turn cap ends the run if it wanders. A pre-tool hook blocks edits to files you marked off limits.
4. Gate four: human review.
   • Output: a draft pull request on a new branch, with a description of what changed and what the agent could not verify.
   • Branch protection requires your normal CI and a developer's approval. The agent cannot merge.
   • Audit: the run record lists the prompt version, the commands executed, the files touched and the cost.

If the developer finds the fix wrong, they close the pull request or comment, and the outcome is recorded as a rejection for later review.

Which guardrails should exist before the first run?

• Allow-listed commands. Claude Code's --allowedTools option takes permission rules such as Bash(git diff *), which allow a command prefix. List what the job needs.
• No prompts nobody can answer. Anthropic documents a dontAsk permission mode that denies any call that would otherwise prompt, intended for locked-down CI runs.
• Hooks for hard stops. The hooks documentation says a PreToolUse hook can block a tool call by exiting with code 2, with its message passed back to the agent.
• Bounded runs. Cap the turns with --max-turns and set a workflow timeout, as the GitHub Actions guidance suggests for cost control.
• Secrets out of reach. The API key sits in the CI secret store. No production credentials, deployment tokens or customer data are present in the job's environment.
• Predictable startup. The documentation recommends --bare for scripted calls so that every machine loads the same configuration. Check the current docs, since defaults change.
• Narrow app permissions. The official GitHub app asks for a wider permission set than this action uses. Anthropic's page describes a custom app limited to contents, issues and pull requests for teams that need that.

For the security habits we check in AI-assisted code, see AI coding tool security mistakes.

What does the agent do alone, with approval, and never?

Area	Alone	Needs a developer	Never
Reading code, issues and CI logs	Yes
Writing tests and edits on a new branch	Yes
Opening a draft pull request	Yes
Merging, approving its own change		A developer merges	Self-approval
Changing dependencies or CI configuration		Yes
Database migrations		Blocked by hook; human writes
Deploying, rotating secrets, touching production data			Yes
Force-pushing or deleting branches			Yes

What goes wrong in practice?

• The fix passes the new test but breaks something untested. The pull request states what was and was not run, and your normal CI and review still apply. The agent adds evidence; it does not replace judgment.
• The issue text is hostile or misleading. Issue bodies are untrusted input. With no network tools, no secrets and a narrow allow-list, injected text has little to act on.
• The run loops or burns budget. The turn cap and timeout end it, and the log shows what it spent.
• The agent edits files it should not. A pre-tool hook blocks the call; repeated blocks are visible in the log and prompt a review of the instructions file.
• Instructions go stale. The instructions file has a named owner and is reviewed when the build commands or conventions change.
• CI does not run on the agent's commits. Anthropic's troubleshooting notes warn that GitHub does not trigger workflows on commits made with the default workflow token, so authentication is set up to avoid that.

How would success be measured?

We would not promise a time saving. We would track:

1. Draft acceptance: pull requests merged after review, merged after heavy edits, and closed.
2. Review effort: time a developer spends per agent pull request, compared with similar human-written ones.
3. Escaped defects: bugs traced to agent-authored changes after merge.
4. CI pass rate on first push for agent branches.
5. Cost per run and cost per merged change, from the run log.
6. Blocked actions per week, as a sign the guardrails are working or the instructions need fixing.

To talk through your repository and where this would help, contact us.