fauxnix
The fauxnix server provides tools to execute bash-like commands on Windows, translate bash commands to PowerShell, and manage the shell session.
Execute bash-style commands: Run Linux-style commands natively on Windows, with output formatted to resemble GNU/Linux tools and automatic handling of text encoding. It supports various commands, pipes, redirections, and variables, and passes through unknown commands for native execution.
Translate bash commands: View the PowerShell equivalent of a bash command without executing it, useful for debugging or learning.
Manage fauxnix session: Inspect the current state of the fauxnix shell session (current directory, environment variables) or reset it to a fresh shell.
fauxnix
Run Linux-style commands on Windows — natively, deterministically, with no VM and no WSL.
fauxnix is a bash→PowerShell translation layer built for AI agents. Your agent keeps writing the
bash it already knows (ls -la | grep foo, find . -name '*.ts' | wc -l, kill -9 1234), and
fauxnix deterministically translates each command into PowerShell, executes it natively, and hands
back output that looks like GNU/Linux: ls -l columns, bash-style error messages, coreutils exit
codes, UTF-8/GBK handled automatically.
npm install -g fauxnix-cli # then point any MCP harness at `fauxnix mcp`$ fauxnix "ls -la src | head -2"
-rw-r--r-- 1 me me 1204 Aug 16 09:12 ast.ts
-rw-r--r-- 1 me me 8192 Aug 16 09:12 cli.ts
$ fauxnix "cat nope.txt"
cat: nope.txt: No such file or directory # not a PowerShell stack traceMeasured: your model is probably worse at PowerShell than you think
Same model (DeepSeek-V4-Pro), same 5 tasks, three execution modes on one Windows machine —
full data in docs/benchmark-deepseek-v4-pro.md and
[`docs/benchmark-ark-models.md](docs/benchmark-ark-models.md):
PowerShell | fauxnix | Git Bash | |
tool calls / unexpected errors | 14 / 9 | 7 / 0 | 4 / 0 |
time (T1–T4) | 163s | 66s | 57s |
Across 7 models on the Volcano Ark Coding Plan, the PowerShell-vs-fauxnix gap held for every model tested — worst case (kimi-k2-thinking): 3.1× slower with 24 error events writing PowerShell vs zero errors through fauxnix. fauxnix lands within ~15% of the real-bash ceiling with no bash toolchain installed.
Related MCP server: wmux
Why
LLM agents are dramatically better at bash than at PowerShell — bash dominates training data, so
models on Windows often produce "looks right, doesn't run" commands (wrong quoting, curl that
isn't curl, mojibake from codepage mismatches, inscrutable CategoryInfo error dumps). Existing
solutions are either a full VM (WSL — heavy, wrong filesystem, separate environment) or plain
shell wrappers (still PowerShell underneath).
fauxnix takes the third road: translate, don't emulate. A large, high-value subset of the Linux command line — file ops, text processing, process management, archives, networking basics — maps cleanly onto PowerShell + .NET. fauxnix implements that subset faithfully and fails loudly and helpfully on what it can't translate, so the agent never gets silently-wrong results.
Labs now train computer-use agents on fleets of real desktops. Reporting in 2026 (The
Information, widely repeated) has OpenAI buying tens of thousands of Mac mini / Mac Studio
boxes — no screen, no keyboard — to reinforcement-learn agents that click, edit, test, and
run bash workflows, and Anthropic renting Mac minis through AWS for the same class of work.
That scoring environment is macOS. Windows users should not have to install a guest Unix to
keep up: the agent keeps writing bash; fauxnix makes the Windows box answer like the box the
agent was trained on. See docs/rfc-computer-use-windows.md.
Install
npm install -g fauxnix-cliOr from source:
git clone https://github.com/20000419/fauxnix && cd fauxnix
npm ci
npm install -g .npm package name is
fauxnix-cli(thefauxnixname on npm belongs to an unrelated 2015 websocket library); the installed command is stillfauxnix.
Requires: Windows with PowerShell 5.1+ (built-in) and Node.js ≥ 18.
PowerShell 7 is an opt-in, CI-tested tier:
$env:FAUXNIX_PS = 'pwsh'
fauxnix check # edition: CoreSet the variable before starting fauxnix or its MCP harness; restart the
harness after changing it. Windows PowerShell 5.1 remains the default. Invalid
values and a missing selected executable fail loudly rather than falling back.
The default is pinned below SystemRoot; pwsh.exe is resolved once from
absolute PATH directories, excluding the current working directory.
See PowerShell 7 support.
Quick start
# one-off commands
fauxnix "ls -la"
fauxnix "grep -rn TODO src | wc -l"
fauxnix "cat log.txt | grep -i error | sort | uniq -c"
# see what a command becomes (great for debugging / learning PS)
fauxnix translate "find . -name '*.log' -mtime +7 -delete"
# check your environment
fauxnix check
fauxnix doctor # check + encoding, harness config, MCP
# write user-level MCP config (idempotent; also --codex/--opencode/--kimi/--qwen)
fauxnix install --claude
# run the MCP stdio server (what agent harnesses connect to)
fauxnix mcptranslate only renders a script and does not read command operands. Because
sed -f needs a script file, translate-only mode asks you to use -e with
inline script text; normal command execution continues to support sed -f.
Unknown commands (git, node, npm, python, cargo, gh, docker, ...) are passed through natively
with argv-style quoting. Windows .cmd/.bat shims necessarily pass through cmd.exe; fauxnix
preserves its supported punctuation and fails loudly for %, embedded double quotes, NUL, and
line breaks rather than passing a different argument.
Use with your agent harness
fauxnix ships an MCP stdio server exposing a bash tool (plus fauxnix_translate and
fauxnix_session). Point any MCP-capable harness at it with
fauxnix install --claude (or --codex / --opencode / --kimi / --qwen).
Idempotent; prints what changed. Manual configs below.
Quickstarts — copy-paste config + a 10-command smoke:
docs/examples/
Claude Code
claude mcp add fauxnix -- fauxnix mcpCodex (~/.codex/config.toml or codex mcp add fauxnix -- fauxnix mcp)
[mcp_servers.fauxnix]
command = "fauxnix"
args = ["mcp"]Note: in non-interactive codex exec mode, MCP tool calls are auto-denied by
the approval layer; pass --dangerously-bypass-approvals-and-sandbox (or run
interactively and approve once).
OpenCode (opencode.json)
{
"mcp": {
"fauxnix": { "type": "local", "command": ["fauxnix", "mcp"] }
}
}Kimi Code — unlike the others, MCP servers live in a JSON file, not the
TOML config: ~/.kimi-code/mcp.json
{
"mcpServers": {
"fauxnix": { "command": "fauxnix", "args": ["mcp"] }
}
}Qwen Code (~/.qwen/settings.json)
fauxnix install --qwenThe installer preserves the rest of settings.json and writes an absolute
Node + package-entry launcher so Qwen startup does not depend on its working
directory or PATH order. See the Qwen example for
the generated JSON shape.
Any MCP client — stdio server: fauxnix mcp. The tool name is bash (override with
FAUXNIX_TOOL_NAME). Tool description already teaches the model the supported subset, so no
system-prompt changes are required.
The MCP session persists cwd, environment variables, export/unset, cd -/OLDPWD, and
positional parameters (set -- / $1 / "$@") across tool calls — it behaves like a logged-in
shell, not a stateless exec. $0 is the MCP tool name (bash / FAUXNIX_TOOL_NAME), not a
Windows path.
What's translated
~105 commands, all output-matched against real GNU coreutils on Windows (Git Bash) during development:
files:
ls cp mv rm mkdir rmdir touch mktemp ln readlink realpath basename dirname stat file du df find chmod chown difftext filters:
grep egrep sed awk sort uniq cut tr— sed/awk scripts are parsed while preparing an executable plan (unsupported constructs throw named errors, never silently misbehave); inspect-onlytranslatekeepssed -ffile reads out of that pathtext I/O:
echo printf cat head tail wc tee nl tac md5sum sha1sum sha256sum base64 seq yes xargs
The curated agent-daily 60 carry a CommandSpec: unknown options fail with a GNU-style
usage error instead of being ignored. The generated docs/command-specs.md
is the exact list, coverage count, option table, and exclusion rationale; fauxnix list --json
exposes the same per-command metadata. find stays unspec'd so predicates like -name still
compile; sed/awk/egrep keep their command-specific parsers; tar remains native to
tar.exe so supported bsdtar options reach the executable. Implemented GNU holes include
cp -n / mv -n / touch -c / tee --append / grep -m / head --lines /
du --max-depth / env -u / ps -f / command -V / date --date=@SECONDS.
shell/system:
cd pwd export unset env printenv ps kill pkill pgrep sleep which type whoami id groups date uname hostname uptime free nproc clear true false test [ [[ : pushd popd dirs sudo timeout man history less more source . eval exit alias set shiftnetwork:
curl wget ping netstat ss ip ifconfig nslookup dig hostarchives:
tar gzip gunzip zcat zip unzip
Plus shell syntax: pipes, && / || / ;, redirections (> >> 2> 2>&1 < &>, /dev/null),
quoting, $VAR $1 $# "$@" set -- shift, ${name:-word} ${name//pat/str}
${name:off:len} ${name[n]} ${#name[@]}, A=(x y z) array assignment, $(...) command
substitution, VAR=x cmd prefixes, ~ expansion, and POSIX-style path normalization
(/tmp, /d/foo → D:\foo).
Exit codes follow bash conventions: 0 ok, 1 fail, 2 usage/serious, 127 command not found, 124 timeout.
How it works
bash command ──parser──▶ AST ──translator──▶ PowerShell script ──executor──▶ selected PowerShell
│
agent ◀── GNU-style output, bash-style errors ◀── UTF-8 framed host protocol ◀┘Deterministic translation, zero LLM calls at runtime.
Each command maps to a generator that emits a self-contained PowerShell block honoring the "Fauxnix contract": string-per-line stdout,
[Console]::Error.WriteLinefor bash-style stderr,$script:fx_exitfor exit codes,$inputfor stdin.The executor wraps every script with UTF-8 enforcement (
[Console]::OutputEncoding,$OutputEncoding,chcp 65001), decodes native output at the process boundary (UTF-8 by default or GBK(936) inansimode), keeps host frames UTF-8, strips CLIXML serialization and PowerShell noise from stderr, and rewrites common PowerShell errors (including zh-CN locale messages) into bash phrasing.Scripts run via
-EncodedCommand(UTF-16LE) and transparently fall back to a temp.ps1file when the 32 KB command-line limit would be exceeded.
Known deviations (honest list)
fauxnix optimizes for the commands agents actually run. Documented deviations:
X=1standalone assignments followexportsemantics (one session-wide environment; bash's shell-var vs exported-var distinction does not exist), and a same-segment prefix is visible to$VARinside the command's own words (Z=in [[ $Z == in ]]is true here, false in bash where word expansion precedes the temporary environment).yesis capped at 65,536 lines — PS 5.1 pipelines cannot signal upstream producers to stop, so an unboundedyes | headwould hang.tail -f,eval,alias, heredocs,env -i/--ignore-environment, background&, and output/fd redirects (>>>2>2>>&>&>>2>&11>&2) on a non-last pipeline stage (echo hi >f | cat) are rejected with operation-specific, actionable error messages instead of misbehaving. Per-stage<remains supported; fully routed per-stage output fds are still tracked by #157. (if/then/elif/else/fi,for x in ...,while/until,case ... esac(;;only;;&/;;&fail loud), backtick substitution,command -v, pipelineread, dotenv-stylesource, word-level$((...))arithmetic expansion,A=(x y z)arrays, and${name//pat/str}/${name:off:len}are supported.)command -v <builtin>prints/usr/bin/<name>where bash prints the bare builtin name; exit codes and empty-result semantics match.chmodmaps only the read-only bit; exec bits are no-ops on Windows.chownis a silent no-op (as in Git Bash).ps auxcolumns are approximations (no per-process CPU% accounting, USER shows?).gzip -c/pipeline stdin is text-faithful, not byte-faithful; file-modegzip fis byte-exact.A pipeline producing exactly one line, piped into
wc -l, counts that line (bash would count 0 if the producer omitted the trailing newline).printf 'x' | md5sumstays byte-exact.sed/awksupport the common subset; hold-space, labels, arrays, loops throw named "not supported" errors at translate time.curl/wgetrefuse loopback/private/reserved addresses (localhost, 127.x, ::1, 10.x, 172.16–31.x, 192.168.x, 169.254.x) as a safety default for agent-driven HTTP.Native-tool pipelines vs encoding: PS 5.1 has a single console-encoding knob, so piping localized admin tools (ipconfig, tasklist — GBK on zh-CN) and UTF-8-native dev tools (node, curl) cannot both decode cleanly mid-pipeline. Default favors UTF-8 dev tools; set
FAUXNIX_NATIVE_ENCODING=ansiwhen your agents grep Chinese output of native Windows admin tools. File reads are always sniffed per file (UTF-8 strict → GBK fallback), so grep/sed/awk over GBK files works in either mode — unlike Git Bash, which only matches the encoding its locale assumes.
Development
npm install
npm test # unit + real-PowerShell integration suite (Windows only, auto-skipped elsewhere)
$env:FAUXNIX_PS = 'pwsh'; npm test # same suite through PowerShell 7
npm run build
npx tsx scratch/run.mjs "any bash command" # quick live checkDifferential vs Git Bash is opt-in (FAUXNIX_DIFF_ORACLE=1; skips if unset or bash.exe is missing — Git Bash is not required). See test/differential/README.md. The 253-case corpus enforces the RFC C-7 minimum of 200 cases and a 95% identity gate. The weekly oracle runs from .github/workflows/differential.yml; two consecutive green scheduled runs are still required release evidence after this gate lands.
Architecture map: src/parser.ts (bash subset → AST) · src/translator.ts (AST → PowerShell +
executor wrapper) · src/executor.ts (spawn, redirects, session persistence) ·
src/commands/*.ts (per-command generators) · src/mcp.ts (MCP server) · src/cli.ts.
Roadmap: docs/rfc-roadmap-to-1.0.md — tracks, milestones, and the RFC process for proposing waves.
Security
Trust model, host protocol, kill semantics, network guard, and reporting: SECURITY.md.
License
MIT © 20000419
Available Tools
3 toolsbashADestructive
Execute a Linux/bash-style command on this Windows machine.
Commands are deterministically translated to PowerShell and executed natively — no WSL or VM. Output is formatted to look like GNU/Linux tooling (ls -l, ps aux, df -h ...), errors look like bash errors, and text encoding (UTF-8/GBK) is handled automatically.
Supported: pipes (|), && / || / ;, redirections (> >> 2> 2>&1 < /dev/null), variables ($VAR $HOME ~), command substitution $(...), and 108+ coreutils-style commands (., :, [, [[, alias, awk, base64, basename, cat, cd, chmod, chown, clear, command, cp, curl, cut, date...). Unknown commands (git, node, npm, python, cargo...) are passed through and executed natively with argv-style quoting. Not supported: heredocs, while/until/case, env -i/--ignore-environment, background jobs. if/then/elif/else/fi, for-in loops, and word-level $((...)) arithmetic expansion are supported.
CWD, environment variables, export/unset and cd persist across calls within this session — a resident PowerShell 5.1 host is started when the MCP session begins (and after reset), so the first bash tool call is already warm. Exit codes follow bash conventions (0 ok, 1 fail, 2 usage/serious, 127 command not found, 124 timeout, 130 cancelled). The tool also returns structuredContent (schemaVersion 1) with stdout/stderr/exitCode/timedOut/cancelled/truncated/sessionId.
Platform requirement: the execution backend is native Windows PowerShell 5.1+. On hosts without PowerShell on PATH (e.g. Linux containers/sandboxes), the bash tool returns exit code 127 with an actionable error instead of running the command.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The bash-style command line to run | |
| timeout_ms | No | Timeout in milliseconds (default 120000) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (destructiveHint true, openWorldHint true). The description adds extensive behavioral detail: deterministic translation to PowerShell, output formatting, encoding handling, persistence of CWD/env across calls, bash-style exit codes, structuredContent return, and platform requirements. This far exceeds what annotations alone offer, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is long, every sentence delivers critical information: execution method, supported/unsupported features, state persistence, exit codes, structured output, and platform constraints. It is well-structured with clear sections and front-loads the core purpose. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool (command execution with many edge cases), and the description covers all critical aspects: translation behavior, supported commands, unsupported constructs, state persistence, exit code semantics, structured content fields, and platform requirements. Even though no output schema is provided, the description explicitly enumerates the structuredContent fields. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both command and timeout_ms have descriptions). The description adds no extra parameter semantics beyond what the schema already states, such as the default timeout. Baseline of 3 is appropriate since the schema fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific action ('Execute a Linux/bash-style command') on a specific platform ('this Windows machine'). It clearly distinguishes itself from siblings like fauxnix_translate (presumably a translation utility) and fauxnix_session (session management). No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists what is supported (pipes, redirections, variables, 108+ coreutils commands) and what is not (heredocs, while/until, env -i, background jobs). It also clarifies that unknown commands (git, node, etc.) are passed through natively. This gives concrete when-to-use and when-not-to-use guidance beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fauxnix_sessionAIdempotent
Inspect or reset the persistent fauxnix shell session (current directory, environment, session id). Actions: "status" (default) or "reset".
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | "status" shows the session state (cwd, tracked env keys); "reset" clears it back to a fresh shell | status |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the effects of each action: status shows session state (cwd, tracked env keys), reset clears to a fresh shell. This enriches the idempotentHint=true and destructiveHint=false annotations by describing what actually changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence plus a brief action list. Every word is informative with no filler. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one enum parameter, no output schema), the description fully covers the tool's purpose and behavior. The combination of description and schema leaves no meaningful gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a detailed enum description. The tool description reiterates the action names but adds no new semantic information beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects or resets a persistent fauxnix shell session, with specific actions enumerated. This distinctly differentiates it from sibling tools bash (executing commands) and fauxnix_translate (translations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for session state inspection or reset) but does not explicitly contrast with sibling tools or provide when-not guidance. The clarity of purpose and sibling names indirectly guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fauxnix_translateARead-onlyIdempotent
Translate a bash-style command into the equivalent PowerShell script WITHOUT executing it. Useful for learning/debugging what fauxnix does under the hood.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The bash-style command line to translate (never executed) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-destructive operation. The description adds behavioral context by emphasizing 'WITHOUT executing it' and that the command is 'never executed', reinforcing safety beyond the annotations. This matches the bar for adding value beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core action and immediate caveat (no execution) in the first sentence, then stating the use case. Every sentence earns its place without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, no output schema, and rich annotations (readOnly, idempotent, non-destructive), the description is complete enough. It explains the translation function, non-execution guarantee, and appropriate use case. The absence of return value detail is acceptable since there is no output schema to contradict, and the use case is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (1 parameter fully described in schema), so the baseline is 3. The description adds minimal parameter information beyond the schema (just reiterates 'bash-style command line'), but it does clarify that the command is never executed, which complements the schema description. No enum parameters exist to add further context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool translates a bash-style command into PowerShell without executing it, specifying the verb 'Translate' and the resource 'bash-style command'. It distinguishes itself from siblings like 'bash' or 'fauxnix_session' by highlighting its non-execution and translation-only purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states this is for learning or debugging what fauxnix does under the hood, providing clear context for when to use it. However, it does not specify when not to use it or mention alternatives, though the sibling 'bash' implies execution which contrasts with this tool's non-execution nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
- First observed
bash - First observed
fauxnix_session - First observed
fauxnix_translate
TDQS
Each tool has a distinct purpose: execute, translate without executing, and manage session state. There is no overlap in functionality, so an agent can unambiguously select the right tool.
Two tools follow a 'fauxnix_' prefix pattern, but the primary tool is simply named 'bash', which breaks the convention. However, this is a deliberate choice for the main entry point and all names are clear and predictable.
With only 3 tools, the server is tightly scoped to its core purpose: executing bash commands, providing translation for debugging, and managing the session. No redundant tools; each earns its place.
The toolset covers the full lifecycle of the domain: execution (bash), understanding/debugging (fauxnix_translate), and session management (fauxnix_session). There are no obvious gaps for the stated purpose.
Maintenance
Related MCP Connectors
Package intelligence MCP for AI agents — 22 tools, 19 ecosystems, AGPL SDK, free.
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
Related MCP Servers
- AlicenseBqualityDmaintenanceHigh-performance MCP server giving AI agents advanced filesystem and automation capabilities on Windows, with 26 tools across file I/O, search, Git, process management, and more.262MIT
- AlicenseNot gradedqualityAmaintenanceA native Windows terminal multiplexer with MCP bridge for AI agents, enabling browser automation, multi-agent coordination, and terminal control.365MIT
- FlicenseNot gradedqualityAmaintenanceEnables AI assistants to execute PowerShell commands, manage files, inspect projects, run Git operations, and monitor system information on Windows through a local MCP server.-
- AlicenseNot gradedqualityBmaintenanceProvides a local Windows control plane for PowerShell and AI CLIs, exposing MCP tools for safe terminal sessions, bounded provider calls, routing, committees, and run receipts.8MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/20000419/fauxnix'
If you have feedback or need assistance with the MCP directory API, please join our Discord server