You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "Master-Frank (via GitHub)" <gi...@apache.org> on 2026/10/09 11:44:55 UTC
[PR] fix(runtime): keep request_sandbox_boundary visible in sandboxed Sessions [maka]
Master-Frank opened a new pull request, #6029:
URL: https://github.com/apache/maka/pull/6029
## Summary
Host binds `request_sandbox_boundary` only when the Session is not Full access, but `tool_search` still deferred it. Models then searched for that name, activated MiniSearch neighbors, and missed the prompt cache.
This PR passes the bound widening tool through the existing `requiredToolNames` hook. The set follows Host binding for the whole Session and does not depend on a live boundary prompt, which would change the provider prefix per Turn.
Full access Sessions still omit the tool. Direction 2 stays with #1382.
Refs #5879
## Verification
- The backend test fails when `prepare()` does not receive the required name, and passes with it.
- `node --test` on `tool-availability`, `deferred-tools-backend`, and the new sandbox-boundary helper cases passed.
- `npm --workspace @maka/runtime run test:dist`: 3752 passed, 13 skipped, 0 failed.
- Hosted composition test `production Host executes a canonical ai-sdk Session against a real provider wire` passed with `request_sandbox_boundary` on the step-0 list.
- `biome format` / `biome lint` clean for the changed files.
- `npm --workspace @maka/runtime run typecheck` passed.
- Did not run root `npm test`, knip, or the Desktop app.
## AI use
Select exactly one:
- [ ] No generative tool made a substantive contribution
- [x] Generative tooling made a substantive contribution
Tool(s) and scope: A coding assistant implemented the Session-stable `requiredToolNames` wiring and wrote the regression tests.
## Checklist
- [x] Tests cover the change and fail without it
- [x] Lint, format, typecheck and the affected suites pass locally
Does this PR entail a change in behavior?
- [x] Yes — described under Summary above
- [ ] No
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(runtime): keep request_sandbox_boundary visible in sandboxed Sessions [maka]
Posted by "Colafornia (via GitHub)" <gi...@apache.org>.
Colafornia merged PR #6029:
URL: https://github.com/apache/maka/pull/6029
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(runtime): keep request_sandbox_boundary visible in sandboxed Sessions [maka]
Posted by "Master-Frank (via GitHub)" <gi...@apache.org>.
Master-Frank commented on PR #6029:
URL: https://github.com/apache/maka/pull/6029#issuecomment-6083359528
> > **Automated review notice:** This comment was posted by an automated review agent. It is not an independent human review and does not replace one.
>
> Reviewed range: `560a27c1f..594329d5` (one commit, first review, no prior findings).
>
> The PR adds `requiredSandboxBoundaryToolNames(hostTools)` and merges its result into the `requiredToolNames` passed to `prepare()`. When the Host binds `request_sandbox_boundary` (Sessions that are not Full access), it is now on the provider tool list from step 0 without a `tool_search` hop. Full access Sessions, where the tool is unbound, see no change. I checked the parts that could interact:
>
> * Required names are filtered by `knownNames`, are added to `step.active`, and never write to the activation map. The tool is therefore callable through gating.
> * Turn-level denial and finalization still remove the tool. `boundaryAwareToolNames()` and the code-mode catalog filter run after `prepare()`, so a required name does not override the "denied for this Turn" or finalization-step removal.
> * The set is computed from the step's Host snapshot, not from a live prompt, so it stays fixed for the Session unless the Host binding changes. A permission-mode change alters the tool set anyway.
> * The composition test now expects the tool on the step-0 list.
>
> No P0-P2 findings.
>
> P3 - the tool is still listed in the `tool_search` inventory. `request_sandbox_boundary` stays searchable, so it remains in the `tool_search` description, and an exact-name search still "activates" a tool that is already visible. The required orchestration tools behave the same way and this is harmless, but excluding required names from the inventory would save a few tokens and avoid a redundant search. This is optional.
>
> P3 - possible conflict with #6028. Both PRs edit `packages/runtime/src/__tests__/deferred-tools-backend.test.ts` in the same hunks: this PR adds `extraTools` to the `backend()` helper input, #6028 adds `loadTurnRuntimeEvents` at the same spot, and both insert tests after the same test. A `git merge-tree` of the two heads (also main+#6028, then this PR) conflicts only in that file. `ai-sdk-turn.ts` auto-merges because the edits are about 30 lines apart. The runtime behaviors work together: required names do not touch the Session activation map that #6028 introduces. Whichever PR lands second needs a small test-file rebase.
>
> No protocol or persisted-schema files are touched, so there is no epoch impact.
>
> Mergeability: merges cleanly into current main (`c11a5336`). CI on `594329d5`: `label` and `test` pass.
Thanks. Required names are now omitted from the tool_search inventory and ranking, so an exact-name search does not activate a tool that is already visible. The deferred-tools helper is aligned with #6028 so the two PRs rebase without a test-file conflict.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(runtime): keep request_sandbox_boundary visible in sandboxed Sessions [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on code in PR #6029:
URL: https://github.com/apache/maka/pull/6029#discussion_r4230433452
##########
packages/runtime/src/__tests__/deferred-tools-backend.test.ts:
##########
@@ -81,6 +85,7 @@ function backend(input: {
toolAvailability?: ToolAvailabilityConfig;
fullSurface?: boolean;
resolveTools?: () => readonly MakaTool[];
+ extraTools?: readonly MakaTool[];
Review Comment:
P3: #6028 adds `loadTurnRuntimeEvents` to this same helper input and inserts tests after the same test, so the two PRs conflict textually in this file. Whichever lands second needs a rebase. The runtime changes themselves do not conflict.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org