@rnbsolucoes/axion-code 0.1.20 → 0.1.22

package/README.md

@@ -287,17 +287,20 @@ Provider stream `tool_call` events now open the TUI approval menu when the
 active permission mode requires review. Approve/Deny records the audited
 decision and returns focus to the chat input. When approved, the TUI executes
 supported guarded-dispatcher tools and prints the bounded result in the
-timeline. Unsupported tools remain explicitly pending until a dedicated adapter
-exists.
+timeline. Successful supported tool results are then sent back into the active
+provider as a follow-up `tool_result` continuation turn, so the agent can use
+the evidence before answering. Unsupported tools remain explicitly pending until
+a dedicated adapter exists.
 
 `axion tool run` exposes the first guarded dispatcher surface. The CLI and TUI
-currently support `Read`, `Glob`, `Grep`, `Write` and `Edit` inside the active
-workspace. Provider tool aliases such as `read_file` and `write_file` are
-normalized to the native tool names before approval/execution. When the active
-permission mode requires approval, execution is allowed only if the supplied
-approval is already approved and matches the exact redacted tool request.
-Shell, MCP, browser, process and unknown tools remain unsupported even when an
-approval exists.
+currently support workspace-local `Read`, `Glob`, `Grep`, `Write` and `Edit`,
+plus governed `Shell`/`Bash`/`PowerShell` commands that run from a workspace
+directory with timeout and bounded output. Provider tool aliases such as
+`read_file`, `write_file` and `run_command` are normalized to native tool names
+before approval/execution. When the active permission mode requires approval,
+execution is allowed only if the supplied approval is already approved and
+matches the exact redacted tool request. MCP, browser, process and unknown tools
+remain unsupported even when an approval exists.
 
 Examples:
 
@@ -310,14 +313,15 @@ axion permission approvals --session smoke --decision pending --json
 axion permission resolve <approval-id> --deny --reason "not needed" --json
 axion tool run Read "{\"path\":\"README.md\"}" --mode full_permission --json
 axion tool run Write "{\"path\":\"notes/out.txt\",\"content\":\"approved\"}" --session smoke --turn turn-1 --approval <approval-id> --mode request_permission --json
+axion tool run Shell "{\"command\":\"echo axion-shell\"}" --session smoke --turn turn-1 --approval <approval-id> --mode request_permission --json
 ```
 
 Security invariants:
 
 - `Full permission` skips only read and non-destructive write tiers.
 - package install, network download/egress, destructive commands, process
-  control, paid generation, browser actions, mutating MCP tools and unknown
-  tools still require approval under `Full permission`.
+  control, shell commands, paid generation, browser actions, mutating MCP tools
+  and unknown tools still require approval under `Full permission`.
 - `YOLO` is the only mode that bypasses every class, and remains explicit user
   opt-in.
 - unknown native tools are default-deny until they are classified.
@@ -360,10 +364,11 @@ This is a functional direction MVP, not the full harness:
 - terminal logo uses Sixel when available and falls back to width-bounded ANSI/block rendering;
 - initial chat splash shows the Axion logo and system name until the first interaction;
 - guarded dispatcher execution is limited to workspace-local `Read`, `Glob`,
-  `Grep`, `Write` and `Edit`; the TUI executes these after approval and shows
-  the result, but the result is not yet fed back into the provider as an
-  iterative `tool_result` turn;
-- shell, MCP, browser, process and unknown tools remain blocked;
+  `Grep`, `Write` and `Edit`, plus governed workspace-scoped shell commands;
+  the TUI executes these after approval and shows the result, then feeds
+  successful supported results back into the provider as an iterative
+  `tool_result` continuation turn;
+- MCP, browser, process and unknown tools remain blocked;
 - no executable Pi RPC bridge yet;
 - no MCP transport execution yet;
 - native subagent execution is prompt-isolated and provider/model-inherited; richer multi-subagent orchestration, streaming and budget telemetry remain next-cycle items.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rnbsolucoes/axion-code",
-  "version": "0.1.20",
+  "version": "0.1.22",
   "description": "Axion Code CLI harness for the Axion ecosystem.",
   "type": "module",
   "repository": {