Think: allow rejecting an execution without auto-continuing the agent

[BradenHartsell]

Problem

Think.rejectExecution(executionId, reason?) currently applies the rejected outcome to the transcript and automatically starts another model turn. This is useful when rejection means "do not perform this particular action, but keep working."

Some approval interfaces also need a second semantic: "the user rejected this action and wants the agent run to pause until they provide a new instruction." In that case, automatically continuing can cause the model to propose alternatives or keep working after the user intended to stop.

These are both valid behaviors, but rejectExecution() currently does not let the caller distinguish them.

Current behavior

This appears intentional. The current implementation routes both durable-pause actions and Codemode executions through _applyExecutionOutcome(), which updates the transcript and triggers auto-continuation so the model can adapt to the rejection.

PR #1656 describes this model-mediated rejection behavior. There is also precedent in the AIChat approval flow for distinguishing ordinary rejection that continues from a deliberately supplied error result that does not auto-continue, as discussed in PR #967.

Suggested API direction

Would the maintainers be open to an optional continuation policy, for example:

await agent.rejectExecution(executionId, reason, {
  autoContinue: false
});

The default could remain true for backward compatibility. With false, Think would still durably reject the pending execution, preserve the rejection outcome, and prevent the rejected action from executing, but it would not start another model turn. A later user message could resume the conversation normally.

The exact API shape is open for discussion. A separate method or a more general resolution policy may fit the project better. Ideally, the behavior would be consistent for both durable-pause actions and Codemode executions.

Expected semantics

• Existing callers retain the current auto-continuation behavior by default.
• autoContinue: false never executes the rejected action.
• The rejection remains durable and idempotent.
• No new model turn begins solely because of that rejection.
• A subsequent user message can continue the conversation normally.

This issue was researched and drafted with AI assistance. The referenced documentation and implementation were checked against the current repository before submission.

[BradenHartsell]

I prepared a small implementation and focused tests here:

main...BradenHartsell:agents:codex/think-reject-auto-continue

The patch is one commit across six files, with 111 additions and 10 deletions. It preserves the existing default and covers both Codemode and durable-pause rejection paths.

GitHub currently reports that this repository only allows collaborators to open pull requests, so I did not attempt to bypass that restriction. If maintainers would like this submitted as a PR, please let me know whether external PR creation can be enabled or whether you prefer another contribution path.

The implementation and this comment were prepared with AI assistance. The current source and focused behavior were checked before posting.

[aron-cf]

Hey @BradenHartsell thanks for the contribution. I'd be happy to take your changeset and open a PR.

One thing I noticed, is that the autoContinue: false short-circuit in _applyExecutionOutcome returns before the batch re-arm that ai-chat (and Think's own client tool-result/tool-approval handlers) always run on the "don't continue" path.

Today it's safe but if a pause were ever rejected while a sibling auto-continuation is pending, this early return would strand that sibling instead of firing it once the batch is whole.

Calling _rearmPendingAutoContinuationForBatch() should ensure this would work in the future without changing the patch behavior.

-    if (options?.autoContinue === false) return true;
+    if (options?.autoContinue === false) {
+      // Re-arm the barrier so a sibling that already opted in fires once the batch is
+      // whole to match the client tool-result/approval path.
+      this._rearmPendingAutoContinuationForBatch();
+      return true;
+    }

[BradenHartsell]

Thanks for catching that. I’ve updated the changeset to re-arm the pending auto-continuation barrier before returning from the autoContinue: false path. That preserves the non-continuing rejection behavior while allowing an already opted-in sibling to continue once the batch is complete.

The update is in commit 12db18ff. The focused Codemode and durable-pause rejection suites pass, along with the existing parallel-batch re-arm regression. Thanks again for reviewing this and offering to open the PR.