Summary
When a SandboxFactory supplies a tools factory, the factory's return value replaces the framework default tool list (read, write, edit, bash, grep, glob) rather than composing with it, and there is no public way to rebuild that default set — the builder is internal to the runtime and not exported from @flue/runtime. An app that supplies a factory just to add one custom tool silently ships an agent with no file or shell tools.
Root cause
Session initialization uses the sandbox factory's tools result as the complete tool list whenever the field is present; the defaults are installed only when it is absent. The default list is built by the internal createTools() in packages/runtime/src/agent.ts, which the package entry does not export, so a tools factory cannot reference it. Nothing fails at build or startup — the loss surfaces later as the model reporting it cannot read or edit files.
Why this matters
Anyone wrapping an external sandbox who wants the stock tool surface plus their own additions hits this. The only options today are hand-reimplementing all six tools against SessionEnv or patching the package to re-export the internal builder.
Expected behavior
A public export returns the same default tool list the framework installs when no tools field is present, so a factory can spread it and append its own tools.
Current workaround and tested fix
A downstream application carries a pnpm patch on @flue/runtime@1.0.0-beta.9 re-exporting the internal builder so its agent composes the defaults with multimodal adapter tools. A source-level fix is implemented with tests on a fork branch: a public createDefaultTools(env, { subagents?, packagedSkills? }) wrapper (the internal task option stays internal, and the task tool is excluded because the framework appends it separately even when a factory is supplied). New tests cover the default names from the public entry and a factory composing the defaults plus a custom tool; the full runtime suite, typecheck, and build are green: steven4354@8a8746e
Summary
When a
SandboxFactorysupplies atoolsfactory, the factory's return value replaces the framework default tool list (read,write,edit,bash,grep,glob) rather than composing with it, and there is no public way to rebuild that default set — the builder is internal to the runtime and not exported from@flue/runtime. An app that supplies a factory just to add one custom tool silently ships an agent with no file or shell tools.Root cause
Session initialization uses the sandbox factory's
toolsresult as the complete tool list whenever the field is present; the defaults are installed only when it is absent. The default list is built by the internalcreateTools()inpackages/runtime/src/agent.ts, which the package entry does not export, so atoolsfactory cannot reference it. Nothing fails at build or startup — the loss surfaces later as the model reporting it cannot read or edit files.Why this matters
Anyone wrapping an external sandbox who wants the stock tool surface plus their own additions hits this. The only options today are hand-reimplementing all six tools against
SessionEnvor patching the package to re-export the internal builder.Expected behavior
A public export returns the same default tool list the framework installs when no
toolsfield is present, so a factory can spread it and append its own tools.Current workaround and tested fix
A downstream application carries a pnpm patch on
@flue/runtime@1.0.0-beta.9re-exporting the internal builder so its agent composes the defaults with multimodal adapter tools. A source-level fix is implemented with tests on a fork branch: a publiccreateDefaultTools(env, { subagents?, packagedSkills? })wrapper (the internaltaskoption stays internal, and thetasktool is excluded because the framework appends it separately even when a factory is supplied). New tests cover the default names from the public entry and a factory composing the defaults plus a custom tool; the full runtime suite, typecheck, and build are green: steven4354@8a8746e