[Feature]: First-class command wrapper policy for tool shells (RTK-style command and output shaping)

Fermée
  • Quelque chose ne va pas ?
#3,660 0 commentaires 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@wsp1911 y travaille déjà.

Depuis le 2/11/2026.

  • #3716 par @wsp1911 — fusionnée

Évaluation

Difficulté
4/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
12/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
rust, shell
Domaine
devtools

Piste de recherche

Start with src/crates/assembly/core/src/agentic/tools/pipeline/tool_pipeline.rs to see the single dispatch point, then read exec_command/command.rs around the cmd schema and max_output_chars. Check native_hooks/output.rs for how updatedInput works in PreToolUse. This is design work, and the issue leaves the first step and the policy location open, so it is not a starting point. Done would mean a maintainer-agreed design, not a patch.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Problem / opportunity

Agent harnesses spend a lot of context on raw shell output (git status, cargo test, ls, rg). Wrapper tools such as RTK take the opposite approach: rewrite the command, run the real one, emit only the slice the model needs.

OpenBitFun has three partial ways to do this today, and none of them sits at the harness layer:

  • User hooks can rewrite the command, but not the output. PreToolUse with updatedInput can replace ExecCommand.cmd. PostToolUse only appends additionalContext (agent-runtime/src/native_hooks/output.rs), so there is no way to trim or replace the tool result.
  • Hooks do not run on remote workspaces. docs/features/agent-hooks.md states hooks are not dispatched for SSH/remote workspaces (remote_workspace_unsupported), which is where context pressure is usually highest.
  • PATH shims work but live below the harness. The remote shell bootstrap prepends $HOME/.local/bin (acp/src/client/remote_shell.rs), so a shim is picked up — but local, remote, docker exec, and WSL paths each need their own shim, the command that actually ran diverges from what the transcript shows, and the user's own shell in the workspace is altered as a side effect.

So a user who wants this must choose between "works only locally" and "works, but invisibly and per-path".

Proposed behavior

One policy inside ToolPipeline, applied before dispatch, so every execution path behaves the same:

  • Opt-in setting, off by default, that declares which command families get wrapped and by which wrapper provider.
  • Applies only to ExecCommand's cmd, and only to single commands. Anything with a pipe, redirection, chaining, or command substitution is left untouched.
  • The effective command is recorded next to the original in the session/transcript. A reader must never believe git status ran when rtk git status did.
  • Permission rules and the existing guard checks keep evaluating the original command; a wrapper prefix must not become a bypass.
  • Wrapper missing or failing: run the original command and surface one notice. No silent success, no silent skip.
  • Naming, settings shape, and provider abstraction are for maintainers to decide; the only hard requirements are the four behavioral ones above.

Optional and separable: a real output-shaping seam after execution, for harness-side trimming with the raw result kept for evidence. Today the only shaping control is coarse (max_output_chars on exec output). Prefer letting the wrapper own trimming first; add this only if a wrapper cannot deliver it.

Notes

Alternatives considered

  • Hooks only: no remote dispatch, and no way to replace tool output.
  • PATH shims only: shell-layer solution with three implementations, invisible in the transcript.
  • An MCP tool instead: an MCP server adds a tool the model must choose to call. Command wrapping has to be transparent; a model-mediated wrapper spends part of what it saves.
  • A MiniApp: runs only while open; a UI surface, not a dispatch lifecycle owner.

Constraints worth stating up front

  • Wrapping must not weaken the permission or guard path (this is the failure mode that matters most).
  • Compound commands must pass through unchanged; a semantic change costs more than the tokens saved.
  • Remote workspaces are a first-class target, not a follow-up: a local-only policy recreates the gap it is meant to close.
  • Upgrade compatibility: new settings default off; older builds must keep working with profiles that carry them.

References

  • src/crates/assembly/core/src/agentic/tools/pipeline/tool_pipeline.rs — single dispatch point shared by all execution paths.
  • src/crates/assembly/core/src/agentic/tools/implementations/exec_command/command.rs — cmd is the field to rewrite (schema around line 715); max_output_chars shows where output size is currently controlled.
  • src/crates/execution/agent-runtime/src/native_hooks/output.rs — updatedInput is PreToolUse-only; additionalContext cannot replace a tool result.
  • docs/features/agent-hooks.md — hooks are not dispatched on remote workspaces.
  • src/crates/interfaces/acp/src/client/remote_shell.rs — remote shell prepends ~/.local/bin, which is why shims work today.
  • Prior art: RTK, a command-rewriting wrapper that trims tool output to save context.

Open questions

  1. First step: a narrow ExecCommand argument transform, or a generic tool-argument middleware other tools can opt into?
  2. Where should the policy live — a user setting only, or also per-workspace / per-connection (a remote workspace often needs a different wrapper binary than the local machine)?
Langage dominant
Rust
Étoiles
2.3k
Forks
236
Merge moyen
13 h 23 min
PR mergées (30 j)
335

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de GCWing/OpenBitFun

Toutes les issues de GCWing/OpenBitFun

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.