The public repository does not contain the coding agent's source
FuXi's LICENSE says the agent's internal implementation is proprietary and unpublished. That settles an important buying decision before you compare model menus: you cannot inspect or fork the agent through this repository. The public files cover documentation and installers, and GitHub hosts its issue tracker. Developers looking for an open-source coding assistant should choose something else. A public download page does not give you control over the program that edits your files.
The documented product is a terminal assistant that reads code, changes files, and runs shell commands. It supports your own model provider and FuXi-managed models, with routing and fallback between providers. English documentation is available alongside a Chinese README. That makes the product accessible to an English-speaking developer, although its documented capabilities remain claims we haven't verified through execution.
What happened when we ran it
Our sandbox record for FuXi commit f70cb3a on October 15, 2026 says we did not run it: the harness had no supported ecosystem for the checkout labeled Python, and found no Dockerfile. We cloned it into a fresh Debian container allocated 3 CPUs and 8 GB of RAM, without secrets or elevated privileges. The supplied record contains no installation, build, or test result.
That leaves execution unverified, rather than failed. There is no failing application command or exception in the supplied record to diagnose. The Python label belongs to the repository classification, while the README describes the distributed application as a Go binary. Those facts refer to different artifacts. Neither establishes that the downloaded agent would work, or fail, in the same container.
Bringing your own provider still requires a FuXi account
The getting-started instructions require a FuXi account even when you supply a provider key. Interactive users sign in through fuxi login; headless users get a setup-token route. Provider settings can live in environment variables or ~/.fuxi/config.yaml, and the wizard asks for an endpoint and model. Organizations that forbid another vendor account have a concrete reason to stop here.
The documentation describes local sessions, checkpoints, and memory, so a conversation can continue across terminal visits. MCP servers load only after explicit configuration, and --strict-mcp-config limits the session to the supplied server configuration. Those controls suit someone who wants to decide which external tools an agent can reach. They also create configuration to review alongside provider access: a model connection and an MCP connection grant different capabilities.
The published download instructions cover macOS, Linux, and Windows. FuXi provides a doctor command whose documented checks include Git and ripgrep, and the v0.1.8 release notes discuss Git for Windows guidance. Treat those instructions as the vendor's route to trying the binary. Our sandbox record provides no evidence about their completion, platform compatibility, or the reliability of automatic updates.
Privacy controls distinguish stored sessions from transmitted prompts
FuXi's data-protection document says anonymous usage telemetry is enabled by default, while crash reports and conversation sharing are off. It also documents no-telemetry and essential-traffic privacy levels. If your organization reviews outbound traffic, these defaults belong in that review before the first work session. Turning off conversation sharing alone doesn't turn off all product traffic.
With your own key, the README says code and prompts go directly to the selected provider. FuXi-managed models receive content to serve requests, according to the same policy. Local transcripts and credentials live under ~/.fuxi/. I appreciate the distinction between local storage and remote inference, but these are vendor statements. The unpublished implementation prevents the source inspection an open-source buyer might expect, and our lab supplied no traffic capture to check them.
Permission modes need scrutiny before unattended use
Release v0.1.8 describes fixes for permission-dialog freezes and a shell approval check that previously mishandled backticks and newlines. Those are relevant changes for a program allowed to execute commands. The notes show maintainers addressing permission behavior, without establishing that every command path is safe. Keep that distinction when deciding how much authority to grant the agent.
The README says sensitive calls normally ask for approval. A planning mode avoids changes, while bypassPermissions removes prompts. Its explicit advice is to use bypass inside a container or virtual machine, with root and sudo rejected on Linux and macOS. I'd keep normal approvals for an initial evaluation and use a disposable working copy. A blocked destructive example in the README cannot establish the safety of arbitrary generated commands.
September activity supports a cautious trial, not an open-source recommendation
The repository was last pushed on September 29, 2026, after v0.1.8 shipped on September 22. GitHub showed 3,342 stars and zero open issues and PRs when checked on October 15. The issue history includes closed requests for contribution guidance and private security reporting. Those are signs of public maintenance, although a small, closed queue gives little evidence about behavior across demanding real projects.
Choose Aider when inspectable source and Git-centered editing matter, or OpenCode when you want an open-source agent with terminal and desktop interfaces. FuXi deserves consideration only if you accept its account requirement and proprietary binary. Before putting it in a work repository, confirm that those terms fit your organization. If the reason you came to GitHub was to own and examine your coding assistant, this repository doesn't supply that option.