JIXUDOCS

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:

DecisionResult
AllowDispatch the Tool normally
AskAppend approval.requested and wait for a durable allow-once or deny decision
DenyRecord 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.

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.