[Bug]: Mandatory PR watcher blocks custom VCS/CI workflows; allow custom providers or full opt-out #22369

Summary

T3's mandatory PR-watching instructions break development workflows using custom VCS/PR and CI systems. When the built-in watcher cannot serve that workflow, the agent still treats T3's instructions as a prohibition on alternative CI monitoring. This turns an unsupported integration into a blocker for otherwise possible work.

Area

Not sure — host-injected agent instructions / PR and CI monitoring.

Steps to reproduce

This describes the reported workflow; it is not a newly executed minimal reproduction.

1. Use T3 with a custom VCS/PR and CI workflow that the built-in PR watcher cannot handle.
2. Ask the agent to monitor CI status and continue development once checks finish.
3. Ask it to use the workflow's own CLI/API or another waiting mechanism.
4. The agent refuses alternative monitoring because T3's host instructions require its watcher and prohibit polling or running another watcher.

Expected behavior

The agent can complete user-authorized CI monitoring through tools appropriate to the project's VCS and CI system. An unsupported built-in integration should not prevent that.

Please provide either:

• An extension point for a custom VCS/PR/CI provider, including status monitoring and completion notifications.
• A setting to fully disable the built-in PR integration, including the injected instructions that mandate linking/watching PRs and prohibit alternative monitoring.

Disabling the integration must change the agent instructions as well as the UI/tools. Hiding controls while leaving the prohibition in place would not resolve the blocker.

At minimum, the watcher mandate should apply only when the watcher supports the actual provider and can monitor the requested PR. Tool availability alone is not sufficient.

Actual behavior

Attempts to arrange CI monitoring repeatedly hit the host-level restriction. The agent explicitly says (translated into English):

"Ordinary waiting is currently prohibited by the T3 host instruction, which requires its watcher."

The relevant injected instruction requires watch_pull_request when available and tells the agent not to poll or run its own watcher. It does not provide an explicit fallback for custom or unsupported providers.

The resulting deadlock is: the required integration cannot handle the workflow, while the agent considers the usable alternatives forbidden.

Impact

Blocks work completely for the affected workflow. The agent cannot carry the development loop through CI completion, and repeated attempts to establish monitoring are rejected on the same instruction-level grounds.

Workaround

No reliable in-T3 workaround established. Asking the agent to use another monitoring mechanism still encounters the host instruction.

Broader issue: configurable host instructions

This is not the first time T3's host-injected instructions have disrupted my development workflow. The PR watcher restriction is one example of a recurring problem: host-level workflow rules prevent the agent from following the development process I actually need.

I strongly want a supported way to disable or configure T3's injected workflow instructions, globally and/or per project. This should cover the instructions themselves, not just individual integrations or UI features. Users need control over which T3 workflow policies apply so that project-specific tooling and development processes remain usable.

Privacy

This report intentionally contains no environment details, private repository or service names, internal URLs, local paths, session identifiers, or session logs.