Proposal: opt-in restricted automation profile for CI and coding-agent workflows

[Etherist]

Proposal: opt-in restricted automation profile for CI and coding-agent workflows

Summary

Would you consider adding an opt-in restricted automation profile for git gtr new that composes the existing machine-readable and side-effect-suppression options into one explicit invocation mode?

This is a feature/hardening proposal rather than a bug report.

I independently evaluated git-worktree-runner for use in an automated coding-agent workflow. The existing worktree isolation, --porcelain output contract, trust model and cleanup safeguards worked well in that evaluation.

One usability opportunity emerged: callers that deliberately want a minimal-side-effect creation path currently need to remember several independent flags.

Existing behaviour

For coding agents, the current documentation recommends:

git gtr new <branch> --porcelain

This already provides important automation properties:

• stable machine-readable output;
• non-interactive operation;
• incompatibility with --editor and --ai;
• explicit hook_status reporting;
• repository .gtrconfig commands remain subject to the existing trust model.

That is a useful baseline.

However, a caller that wants to suppress optional setup side effects as well currently needs something like:

git gtr new <branch> \
  --porcelain \
  --no-hooks \
  --no-copy

Potentially --no-fetch may also be selected independently when network-free operation is required.

Use case

In CI systems, coding-agent harnesses, evaluation environments and other unattended workflows, it can be useful to request a deliberately restricted worktree-creation contract where:

1. the worktree is created;
2. the path and branch are returned through the normal stable porcelain contract;
3. configured post-create hooks are not executed; and
4. configured files are not copied into the new worktree.

The existing individual options already support this behaviour.

The proposal is therefore mainly about providing one explicit, auditable invocation profile rather than adding new underlying capabilities.

Proposed direction

For example, an additive option such as:

--restricted

or:

--automation-restricted

could conceptually imply:

--porcelain
--no-hooks
--no-copy

The exact name and semantics are of course up to the project.

I would suggest leaving fetch behaviour independent:

--no-fetch

could still be added explicitly by callers that require offline or deterministic use.

Likewise, existing rules around worktree creation, branch collisions and --force would remain unchanged rather than being redefined by this profile.

Why this may be useful

The benefit is primarily reduction of integration error.

Today an automation framework that wants this restricted behaviour must know and correctly combine several negative options.

A named profile would provide a small documented contract that a CI system or coding-agent harness could request directly.

For example:

git gtr new agent/task --restricted

would communicate the caller's intent more clearly than requiring each integration to independently define the same flag bundle.

It could also make automated use easier to audit because the invocation itself declares that optional repository setup actions are intentionally being suppressed.

Backwards compatibility

I would expect this to be entirely opt-in.

Existing commands and configuration would retain their current behaviour.

For example:

git gtr new feature
git gtr new feature --porcelain

would remain unchanged.

Only callers explicitly selecting the new profile would receive the additional restrictions.

The profile should not silently alter existing configuration or change the semantics of existing flags.

Cross-platform and dependency considerations

Because the proposed behaviour is composed from existing git gtr options, it should not require new platform-specific behaviour or external dependencies.

Ideally it would retain the project's existing macOS, Linux and Windows Git Bash support.

Fail-safe behaviour

If the implementation introduces any genuinely incompatible option combinations, I would favour a clear non-zero error rather than silently ignoring the conflict.

Existing compatibility rules — such as --porcelain being incompatible with --editor and --ai — could simply continue to apply.

Testing/documentation considerations

If the feature is considered worthwhile, possible regression coverage could verify that the restricted profile:

• emits the existing porcelain output contract;
• does not execute post-create hooks;
• does not perform configured file copying;
• leaves normal git gtr new and --porcelain behaviour unchanged; and
• behaves consistently across the platforms already supported by the project.

The README/help text and agent-usage documentation could then document the profile alongside the existing automation guidance.

Non-goals

This proposal is not intended to:

• replace the existing .gtrconfig trust model;
• change existing --porcelain semantics;
• prohibit legitimate --force --name parallel-worktree workflows;
• prohibit fetching globally;
• change cleanup/destructive-operation safeguards; or
• suggest that the current agent workflow is unsafe.

It is intended only as an optional convenience/hardening profile for callers that explicitly want worktree creation with fewer setup side effects.

I searched the existing issue history for similar safe/restricted automation, --porcelain, --no-hooks and --no-copy proposals before drafting this and did not find an equivalent request.