bashkit: Bash を埋め込み可能で multi-tenant な Agent 向け virtual sandbox にする

最近の Agent workflow では、かなり古典的な問題がまた前面に出ています。モデルに「command を実行する力」は与えたい。でも本物の machine をそのまま渡したくはない。

よくあるやり方は大きく 2 つです。

本物の shell を渡して、権限・container・監査で周辺を固める;
自前で制限付き tool を少数だけ用意する。

前者は柔軟ですが、隔離と安全性のコストが重い。後者は安全寄りですが、grep、find、sed、tar、jq、redirect、pipe、flow control が欲しくなった瞬間に、結局中途半端な shell を自作し始めることになります。

今日書いておきたい everruns/bashkit は、まさにその間を狙った project です。これは「shell の外側に permission check を足す」発想ではなく、Rust process の中に制御可能な Bash runtime を作る方向を取っています。command、filesystem、resource limits、network access、snapshot / restore、language bindings まで含めて、すべてが embeddable・isolated・multi-tenant・Agent-friendly という軸で整理されています。

GitHub repository page、README、release page を 2026-06-23 時点で見ると、この repository は 179 stars、19 forks、主要言語は Rust。作成日は 2026-01-31、公開上の最新更新日は 2026-06-23 です。license は MIT。最新 release は v0.11.0 で、公開日は 2026-06-16。project site は bashkit.sh です。

Project overview

項目	内容
Repository	everruns/bashkit
位置づけ	multi-tenant / Agent 向けの virtual Bash interpreter
Stars	179
Forks	19
主要言語	Rust
作成日	2026-01-31
最終更新日	2026-06-23
License	MIT
Latest release	v0.11.0
Release date	2026-06-16
Project site	bashkit.sh

解いているのは「command を実行できるか」ではなく「shell を埋め込み capability にできるか」

bashkit でまず面白いのは、terminal UX ではなく runtime capability として shell を見ていることです。

README 冒頭で自分をこう説明しています。

virtual Bash interpreter;
virtual file system;
multi-tenant environments;
written in Rust。

つまり、これは別の terminal app でもなければ、単なる SSH relay でもありません。host application が Bash という能力そのものを library として取り込むための project です。

これは今の Agent system にかなり合っています。実際に多くの場面で必要なのは「shell window」そのものではなく、

1 回の task 内で script 的な操作を組み合わせること;
tenant ごとに実行環境を分離すること;
外部 process の fork/exec に依存しないこと;
state を制限・保存・復元・再現できること。

この前提に立つと、本物の shell は唯一の正解ではなく、むしろ product に埋め込むには重すぎることがあります。

面白いのは、よく使う command 群をかなり本気で Rust に持ち込んでいること

README の公開情報によると、bashkit は現在 156 built-in commands を持ち、その中心思想はかなり明快です。

process を spawn しない;
real filesystem を直接触らない;
network は default deny;
実行は process 内で完結させる。

command surface もかなり広いです。echo、cat、ls のような基本だけではなく、

grep、rg、sed、awk、head、tail、sort、uniq;
mkdir、rm、cp、mv、chmod、readlink、tar、zip;
csv、json、yaml、template、envsubst;
assert、retry、verify、parallel、patch のような automation 寄り command;
feature を有効化すると git、python、node、deno、sqlite まで試せる。

この意味は大きいです。bashkit は「安全な数個の command」だけを見せる toy ではなく、実際に shell workflow を成立させるだけの幅を持たせようとしています。

Agent に必要なのは、たいてい高度な system programming ではありません。むしろ、

pipe;
redirect;
text processing;
file tree operation;
小さな script control flow。

こうした地味な primitives が揃っているかどうかで、使い勝手は大きく変わります。

security model が「呼び出し側が気を付ける」ではなく、最初から閉じている

README でかなり強く打ち出されているのが secure by default です。そこで明示されている default は次の通りです。

新しい process を作らない;
real filesystem に触れない;
明示的に許可しない限り network に出ない;
command 数、loop、function depth、output size、filesystem size などに limit を掛ける。

これは「本物の shell を渡して注意深く運用する」モデルより、はるかに product-oriented です。

特に multi-tenant や Agent 実行では、難しいのは command を動かすことそのものより、

無限 loop をどう止めるか;
output 爆発をどう防ぐか;
tenant 越しの file access をどう遮断するか;
自動化 script の勝手な network request をどう止めるか;
実行結果をどう監査・再現するか。

README では、別途 threat model を持ち、280+ threats を分析・緩和したとも書かれています。この数字だけで security を証明できるわけではありませんが、少なくとも「安全」と言いながら実質ノーガード、というタイプの project ではなさそうです。

単なる shell library ではなく、明確に Agent runtime を見ている

bashkit でもう 1 つ今っぽいのが、単に Bash interpreter を出すだけでなく、BashTool という層を前面に出していることです。

README が説明しているのは、

discovery metadata を持つ;
system prompt を持つ;
execution object を持つ;
streaming output に対応する。

つまりこれは伝統的な shell embedding library の書き方ではなく、かなり直接的に LLM / Agent tool の形へ寄せています。README には coding agent 向け skill の導入例まであります。

ここはかなり重要です。多くの project は結果的に Agent から使えるだけで、Agent を第一利用者として設計しているわけではありません。bashkit はそこが違って見えます。

host が tool として公開しやすい;
tool description を model に見せやすい;
output を stream しやすい;
runtime 自体が virtual で controllable で reproducible。

オンライン Agent platform、automation backend、coding assistant、workflow engine を作る側には、この切り口はかなり魅力的です。

virtual filesystem と snapshotting によって、shell wrapper ではなく orchestratable runtime になっている

私が特に面白いと思ったのは、bashkit が filesystem state も runtime design の一部として扱っていることです。

README に出てくる VFS は、

InMemoryFs;
OverlayFs;
MountableFs;
optional な RealFs backend。

つまり host application は、単なる string evaluator としてではなく、

どの directory tree を見せるか;
どこまでが pure memory か;
どこまでを overlay にするか;
現実の filesystem をどれだけ露出するか。

といった条件ごとに shell 環境を組み立てられます。

さらに snapshotting があるので、この model は checkpoint / resume できる shell runtime に近づきます。README では shell state と VFS contents を serialize できる例が示されていて、長い task、replay、failure recovery、audit に向いています。

単発の opaque subprocess ではなく、保存・再開・再現できる execution environment として見られるのが bashkit の大きな特徴です。

multi-language binding があるので、Rust 以外の stack にも入れやすい

bashkit 本体は Rust ですが、README には次の binding 方向が明記されています。

Python via PyO3;
JavaScript / TypeScript via NAPI-RS;
Node.js、Bun、Deno 向け integration。

これはかなり現実的です。Agent runtime を product にする team が、必ずしも Rust で backend を書いているとは限りません。Node service に入れたい場合もあるし、Python orchestration layer に差し込みたい場合もあります。

最初から binding 層を意識している project は、特定言語コミュニティ向け小物というより、基盤 component に育ちやすいです。

境界も比較的はっきりしている

公開情報を見る限り、bashkit は「万能 sandbox」だと装っていないのも良いところです。

設計として近いのは、

高カバレッジの virtual shell runtime;
script、text processing、workflow orchestration に向く tool layer;
default deny な Agent execution environment。

逆に言えば、

任意の third-party binary をそのまま動かしたい;
本物の Linux userland を完全再現したい;
host process model にそのまま乗りたい;
制限なしの network や disk access が必要。

こうした要件では、container、microVM、または本物の shell の方が適しています。

つまり bashkit はそれらを置き換えるというより、その手前にある より軽く、より埋め込みやすく、より Agent-friendly な中間層 を作ろうとしているわけです。

なぜ追っておきたいのか

この project の価値は、「Bash を Rust で書き直した」こと自体ではありません。むしろ大事なのは、次の需要を正面から見ていることです。

多くの product は Agent に少し shell 能力を与えたい。でもその代償として host boundary 全体を壊したくはない。

bashkit の方針はかなり明快です。

Rust で shell と多数の command を process 内実装する;
VFS、resource limit、network allowlist で default boundary を守る;
snapshotting、多言語 binding、BashTool で product workflow に入れる;
multi-tenant と Agent を主目的として扱う。

この方向が育てば、bashkit は container や本物の shell の代替というより、Agent platform と controlled execution の間に置かれる新しい抽象 になっていきそうです。

まとめ

everruns/bashkit の面白さは、「Rust で Bash が動く」ことよりも、Bash を embeddable・isolated・rate-limited・snapshot-aware・Agent-consumable な runtime capability にしようとしている点にあります。

virtual filesystem、default deny の security model、156 built-in commands、多言語 binding、Agent tool contract を 1 つの設計にまとめていて、狙いはかなり一貫しています。local shell user のための便利ツールというより、次世代の automation と multi-tenant execution に向けた基礎部品です。

Agent に shell を与えたいが、host environment はそのまま渡したくない。そんな課題を考えているなら、bashkit はかなり見ておく価値があります。