JIXU DOCUMENTATION
Tools and safety
Permission, scope, durable approval, and the limits Jixu states explicitly.
Tools act outside the Kernel. Their requests and outcomes use the same durable Event path as model work.
Permission is evaluated before dispatch
The reference Tool catalogue resolves ordered policy rules to one of three outcomes:
| Decision | Result |
|---|---|
| Allow | Dispatch the Tool normally |
| Ask | Append approval.requested and wait for a durable allow-once or deny decision |
| Deny | Record a typed Tool failure without invoking the implementation |
Approval survives Replay and reopen because it is part of the Thread history. UI state is not the approval authority.
File scope
jixu-tools-node defaults to workspace-bounded file access. Lexical and symbolic-link escapes fail with a typed deterministic error.
The reference TUI explicitly discloses its broader process scope so absolute paths requested by the user behave consistently across file Tools and Bash. A different application should choose its scope deliberately.
Bash boundary
No OS sandbox
Permission controls decide whether Bash is dispatched. They do not inspect a shell command or prevent destructive operations. Bash runs with the permissions of the Jixu process.
Keep Bash on ASK unless you accept that risk. Prefer a backed-up, disposable, containerized, or otherwise isolated workspace for untrusted operations.
The first-party Bash Tool separately manages one foreground process lifetime. Timeout and cancellation terminate the managed process group or tree and preserve bounded partial output when termination is confirmed. If Jixu cannot confirm termination or output-pipe closure within its bounds, the Tool outcome remains indeterminate instead of being reported as a safe timeout. This lifecycle behavior does not create containment or undo external side effects.
Network Tools
The first-party Jina adapter provides bounded web_search and web_read Tools. Credentials remain inside the adapter closure and never enter Tool descriptors, Events, errors, or Signals.
Requests are normalized and bounded. Authentication, rate limit, timeout, cancellation, malformed response, and upstream failure retain typed outcomes instead of leaking raw upstream bodies.
Indeterminate outcomes
A Tool exception after dispatch may leave the external outcome unknown. Jixu preserves the pending Effect identity and enters a visible waiting boundary. It does not retry a potentially non-idempotent action as if nothing happened.
Leaving that boundary requires external verification and an explicit durable decision for each retained Effect:
| Decision | What it records |
|---|---|
occurred | The action happened, without inventing a Tool result |
not_occurred | The action did not happen; any later attempt must be a new ordinary Tool call |
abandoned_unknown | The uncertainty is accepted without claiming success or failure |
Use thread.resolveToolOutcome({ effectId, resolution }) in a Framework application or /resolve in the reference TUI. Partial resolution of a parallel unknown batch remains waiting. The final decision creates one ordinary Agent continuation containing the accepted decisions and original bounded failure evidence; it never redispatches the old Tool Effect automatically.
Approval is not outcome resolution. Approval decides whether a Tool may dispatch; resolution records what was learned after a dispatched action became uncertain.