…version

#3723 rewrote `should handle control responses when stdin closes
before replies` in a way that flipped its semantics:

- Old: canUseTool sleeps 1s before allowing; asyncGenerator awaits
  `inputStreamDonePromise` so stdin closes WHILE the control reply
  is still in flight; expects `original content` (the in-flight
  tool must NOT execute). Tests CLI robustness when stdin closes
  before replies — matching the test name.

- New: canUseTool returns `allow` immediately; stdin stays open
  until the second result arrives; expects `updated`. Requires
  the LLM to actually call write_file → receive tool result →
  reply 'done'. The test name still says "stdin closes before
  replies", but it no longer tests that.

The new version times out (testTimeout 5min, retry x2 = 900s) on
both macOS and Linux on every push since #3723, because it depends
on LLM tool-calling behavior that isn't deterministic on the CI
endpoint. CI history shows the pre-#3723 version was stable across
30+ runs.

This restores only the test file. The shared permissionFlow,
coreToolScheduler/Session wiring, and e2e workflow `npm run bundle`
step from #3723 are kept intact.

…version (#3777)

* fix(test): restore abort-and-lifecycle stdin-close test to pre-#3723 version

#3723 rewrote `should handle control responses when stdin closes
before replies` in a way that flipped its semantics:

- Old: canUseTool sleeps 1s before allowing; asyncGenerator awaits
  `inputStreamDonePromise` so stdin closes WHILE the control reply
  is still in flight; expects `original content` (the in-flight
  tool must NOT execute). Tests CLI robustness when stdin closes
  before replies — matching the test name.

- New: canUseTool returns `allow` immediately; stdin stays open
  until the second result arrives; expects `updated`. Requires
  the LLM to actually call write_file → receive tool result →
  reply 'done'. The test name still says "stdin closes before
  replies", but it no longer tests that.

The new version times out (testTimeout 5min, retry x2 = 900s) on
both macOS and Linux on every push since #3723, because it depends
on LLM tool-calling behavior that isn't deterministic on the CI
endpoint. CI history shows the pre-#3723 version was stable across
30+ runs.

This restores only the test file. The shared permissionFlow,
coreToolScheduler/Session wiring, and e2e workflow `npm run bundle`
step from #3723 are kept intact.

* test(integration): add timeout and unify loop into race chain

Address review feedback on the restored test:

- firstResultPromise / secondResultPromise now have a 30s setTimeout
  reject path, matching the pattern used by canUseToolCalledPromise
  and inputStreamDonePromise (15s). Without these, a hang in the
  result stream falls back to the global Vitest testTimeout (5min)
  with no useful diagnostic.

- loop() is now retained as `loopPromise` and joined into the await
  chain via `Promise.race`. If the iterator throws or the consumer
  exits unexpectedly, the failure surfaces directly to the test
  instead of becoming an unhandled rejection while the test waits
  on side-channel promises.

* test(integration): close pseudo-pass paths in stdin-close lifecycle test

Address review feedback. Each change maps to a specific finding:

- Guard canUseTool by toolName === 'write_file' AND file_path against
  the target absolute path. The model may issue read_file or call
  write_file with an unexpected path; those must not satisfy the
  permission-control timing harness, otherwise the test could pass
  without exercising the intended path.

- Capture the second SDK result and assert it's defined, so the
  Promise.race below can no longer short-circuit silently.

- Replace `Promise.race([..., loopPromise])` with a rejection-only
  loopError partner. Loop completion alone (e.g. iterator ends before
  canUseTool is invoked) must not short-circuit the awaited
  milestones; only loop errors should fail the test.

- Restore absolute path via `helper.getPath('test.txt')` and embed it
  in the prompt, so the file the test asserts on is unambiguously
  the same one the model is asked to write.

- Wrap timing promises in a `boundedPromise` helper that clears its
  timeout on resolve, eliminating dangling timers on success runs.

- Drop the unconditional `console.log(JSON.stringify(...))` in the
  consumer loop to reduce CI retry noise.

Out of scope (acknowledged but deferred): the test still requires
the model to actually emit a write_file tool call; with the new
15s/30s bounded timeouts, an LLM that fails to call write_file now
fails fast with a labeled error ("canUseTool callback not called
timeout after 15000ms") instead of hanging to the global 5-min
testTimeout. Making the test fully model-independent would require
a control-only path that doesn't go through tool dispatch — out of
scope for this regression fix.

* test(integration): defer phase timers in stdin-close lifecycle test

Address review suggestion: the 15s budgets on canUseToolCalled and
inputStreamDone started counting at promise creation, but those phases
only begin after firstResult (30s budget) resolves. On a slow CI run
where the first LLM round-trip exceeds 15s, those timers would reject
before their phase even starts, surfacing a misleading
"canUseTool callback not called" error when the actual cause was
first-result latency.

Add an explicit `startTimer()` to boundedPromise and arm each timer
only when its phase actually begins:

- firstResult: armed immediately (begins with the query).
- canUseToolCalled / inputStreamDone / secondResult: armed inside
  createPrompt right after firstResult resolves, so first-turn latency
  cannot eat into their budgets.

This also makes timeout errors point at the correct phase if any of
them does fire.

…#3723 version

…version (#3777)

* fix(test): restore abort-and-lifecycle stdin-close test to pre-#3723 version

#3723 rewrote `should handle control responses when stdin closes
before replies` in a way that flipped its semantics:

- Old: canUseTool sleeps 1s before allowing; asyncGenerator awaits
  `inputStreamDonePromise` so stdin closes WHILE the control reply
  is still in flight; expects `original content` (the in-flight
  tool must NOT execute). Tests CLI robustness when stdin closes
  before replies — matching the test name.

- New: canUseTool returns `allow` immediately; stdin stays open
  until the second result arrives; expects `updated`. Requires
  the LLM to actually call write_file → receive tool result →
  reply 'done'. The test name still says "stdin closes before
  replies", but it no longer tests that.

The new version times out (testTimeout 5min, retry x2 = 900s) on
both macOS and Linux on every push since #3723, because it depends
on LLM tool-calling behavior that isn't deterministic on the CI
endpoint. CI history shows the pre-#3723 version was stable across
30+ runs.

This restores only the test file. The shared permissionFlow,
coreToolScheduler/Session wiring, and e2e workflow `npm run bundle`
step from #3723 are kept intact.

* test(integration): add timeout and unify loop into race chain

Address review feedback on the restored test:

- firstResultPromise / secondResultPromise now have a 30s setTimeout
  reject path, matching the pattern used by canUseToolCalledPromise
  and inputStreamDonePromise (15s). Without these, a hang in the
  result stream falls back to the global Vitest testTimeout (5min)
  with no useful diagnostic.

- loop() is now retained as `loopPromise` and joined into the await
  chain via `Promise.race`. If the iterator throws or the consumer
  exits unexpectedly, the failure surfaces directly to the test
  instead of becoming an unhandled rejection while the test waits
  on side-channel promises.

* test(integration): close pseudo-pass paths in stdin-close lifecycle test

Address review feedback. Each change maps to a specific finding:

- Guard canUseTool by toolName === 'write_file' AND file_path against
  the target absolute path. The model may issue read_file or call
  write_file with an unexpected path; those must not satisfy the
  permission-control timing harness, otherwise the test could pass
  without exercising the intended path.

- Capture the second SDK result and assert it's defined, so the
  Promise.race below can no longer short-circuit silently.

- Replace `Promise.race([..., loopPromise])` with a rejection-only
  loopError partner. Loop completion alone (e.g. iterator ends before
  canUseTool is invoked) must not short-circuit the awaited
  milestones; only loop errors should fail the test.

- Restore absolute path via `helper.getPath('test.txt')` and embed it
  in the prompt, so the file the test asserts on is unambiguously
  the same one the model is asked to write.

- Wrap timing promises in a `boundedPromise` helper that clears its
  timeout on resolve, eliminating dangling timers on success runs.

- Drop the unconditional `console.log(JSON.stringify(...))` in the
  consumer loop to reduce CI retry noise.

Out of scope (acknowledged but deferred): the test still requires
the model to actually emit a write_file tool call; with the new
15s/30s bounded timeouts, an LLM that fails to call write_file now
fails fast with a labeled error ("canUseTool callback not called
timeout after 15000ms") instead of hanging to the global 5-min
testTimeout. Making the test fully model-independent would require
a control-only path that doesn't go through tool dispatch — out of
scope for this regression fix.

* test(integration): defer phase timers in stdin-close lifecycle test

Address review suggestion: the 15s budgets on canUseToolCalled and
inputStreamDone started counting at promise creation, but those phases
only begin after firstResult (30s budget) resolves. On a slow CI run
where the first LLM round-trip exceeds 15s, those timers would reject
before their phase even starts, surfacing a misleading
"canUseTool callback not called" error when the actual cause was
first-result latency.

Add an explicit `startTimer()` to boundedPromise and arm each timer
only when its phase actually begins:

- firstResult: armed immediately (begins with the query).
- canUseToolCalled / inputStreamDone / secondResult: armed inside
  createPrompt right after firstResult resolves, so first-turn latency
  cannot eat into their budgets.

This also makes timeout errors point at the correct phase if any of
them does fire.

…QwenLM#3723)

* docs: scaffold branch for QwenLM#3247 tool execution unification

Placeholder commit to establish the branch for PR creation.
Actual refactoring will be done in subsequent commits.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* feat(core): add shared permission flow for tool execution unification

This addresses QwenLM#3247 by consolidating duplicated tool execution behavior
across Interactive, Non-Interactive, and ACP modes behind shared execution
utilities.

- Add permissionFlow.ts: shared L3→L4 permission evaluation logic
- Add permissionFlow.test.ts: comprehensive test coverage (17 tests)
- Export from index.ts for use across all execution modes

Why: Permission handling logic was duplicated in CoreToolScheduler and
Session.runTool(). This shared module ensures consistent behavior across
all modes and provides a single source of truth for future fixes.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* fix(e2e): add bundle step to E2E workflow and fix canUseTool test

- Add 'npm run bundle' to E2E workflow so dist/cli.js exists for SDK tests
- Fix 'should handle control responses when stdin closes before replies' test:
  - Use helper.getPath() for absolute file path
  - Make prompt explicitly invoke write_file tool
  - Remove inputStreamDonePromise timeout that caused false failures
  - Add q.endInput() to signal stdin done
  - Assert canUseTool was called and file content is updated

* fix(core): wire evaluatePermissionFlow() and address PR review feedback

Address review feedback on PR QwenLM#3723:
- Wire evaluatePermissionFlow() in coreToolScheduler.ts (both call sites)
- Wire evaluatePermissionFlow() in Session.ts (ACP mode)
- Delete TOOL_EXECUTION_UNIFICATION.md (had literal \n artifacts)
- Add PermissionFlowPermission union type for stronger typing
- Document the 'default' permission state in docstring
- Use needsConfirmation/isPlanModeBlocked/isAutoEditApproved helpers

---------

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

…#3723 version (QwenLM#3777)

* fix(test): restore abort-and-lifecycle stdin-close test to pre-QwenLM#3723 version

QwenLM#3723 rewrote `should handle control responses when stdin closes
before replies` in a way that flipped its semantics:

- Old: canUseTool sleeps 1s before allowing; asyncGenerator awaits
  `inputStreamDonePromise` so stdin closes WHILE the control reply
  is still in flight; expects `original content` (the in-flight
  tool must NOT execute). Tests CLI robustness when stdin closes
  before replies — matching the test name.

- New: canUseTool returns `allow` immediately; stdin stays open
  until the second result arrives; expects `updated`. Requires
  the LLM to actually call write_file → receive tool result →
  reply 'done'. The test name still says "stdin closes before
  replies", but it no longer tests that.

The new version times out (testTimeout 5min, retry x2 = 900s) on
both macOS and Linux on every push since QwenLM#3723, because it depends
on LLM tool-calling behavior that isn't deterministic on the CI
endpoint. CI history shows the pre-QwenLM#3723 version was stable across
30+ runs.

This restores only the test file. The shared permissionFlow,
coreToolScheduler/Session wiring, and e2e workflow `npm run bundle`
step from QwenLM#3723 are kept intact.

* test(integration): add timeout and unify loop into race chain

Address review feedback on the restored test:

- firstResultPromise / secondResultPromise now have a 30s setTimeout
  reject path, matching the pattern used by canUseToolCalledPromise
  and inputStreamDonePromise (15s). Without these, a hang in the
  result stream falls back to the global Vitest testTimeout (5min)
  with no useful diagnostic.

- loop() is now retained as `loopPromise` and joined into the await
  chain via `Promise.race`. If the iterator throws or the consumer
  exits unexpectedly, the failure surfaces directly to the test
  instead of becoming an unhandled rejection while the test waits
  on side-channel promises.

* test(integration): close pseudo-pass paths in stdin-close lifecycle test

Address review feedback. Each change maps to a specific finding:

- Guard canUseTool by toolName === 'write_file' AND file_path against
  the target absolute path. The model may issue read_file or call
  write_file with an unexpected path; those must not satisfy the
  permission-control timing harness, otherwise the test could pass
  without exercising the intended path.

- Capture the second SDK result and assert it's defined, so the
  Promise.race below can no longer short-circuit silently.

- Replace `Promise.race([..., loopPromise])` with a rejection-only
  loopError partner. Loop completion alone (e.g. iterator ends before
  canUseTool is invoked) must not short-circuit the awaited
  milestones; only loop errors should fail the test.

- Restore absolute path via `helper.getPath('test.txt')` and embed it
  in the prompt, so the file the test asserts on is unambiguously
  the same one the model is asked to write.

- Wrap timing promises in a `boundedPromise` helper that clears its
  timeout on resolve, eliminating dangling timers on success runs.

- Drop the unconditional `console.log(JSON.stringify(...))` in the
  consumer loop to reduce CI retry noise.

Out of scope (acknowledged but deferred): the test still requires
the model to actually emit a write_file tool call; with the new
15s/30s bounded timeouts, an LLM that fails to call write_file now
fails fast with a labeled error ("canUseTool callback not called
timeout after 15000ms") instead of hanging to the global 5-min
testTimeout. Making the test fully model-independent would require
a control-only path that doesn't go through tool dispatch — out of
scope for this regression fix.

* test(integration): defer phase timers in stdin-close lifecycle test

Address review suggestion: the 15s budgets on canUseToolCalled and
inputStreamDone started counting at promise creation, but those phases
only begin after firstResult (30s budget) resolves. On a slow CI run
where the first LLM round-trip exceeds 15s, those timers would reject
before their phase even starts, surfacing a misleading
"canUseTool callback not called" error when the actual cause was
first-result latency.

Add an explicit `startTimer()` to boundedPromise and arm each timer
only when its phase actually begins:

- firstResult: armed immediately (begins with the query).
- canUseToolCalled / inputStreamDone / secondResult: armed inside
  createPrompt right after firstResult resolves, so first-turn latency
  cannot eat into their budgets.

This also makes timeout errors point at the correct phase if any of
them does fire.