FyAgent: A Local Control Panel for AI Tool Configuration
For You Agent——AI 时代的个人随身数字人格。把你的模型、AI 账号、技能、提示词和工作方式，带到每一个 AI 工具里。
At a glance
- What is it?
- FyAgent is a Rust and Tauri desktop app that centralises model, skill, MCP, prompt and memory settings for a list of AI coding tools. It is source-available under a noncommercial licence, and the README itself warns you to back up before upgrading.
- Who is it for?
- Adopt FyAgent if you already run several of the supported tools and want one place to see and edit their model, MCP, prompt and memory settings, and if a noncommercial licence suits you. Do not adopt it if you need commercial use rights, an MSI or portable Windows build, Linux support, or a stable release line, because the README states the project is still in active development and asks you to back up important configuration before upgrading.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The configuration sprawl FyAgent is trying to contain
If you use more than one AI coding assistant, your settings live in more than one place. Each tool keeps its own model and provider configuration, its own MCP server list, its own prompt files, and in some cases its own memory directory. FyAgent's stated target is people already using AI agents and assistants who want the origin of the model, the connected tools, the skills, the instructions and the saved configuration gathered into one local desktop application. The README frames the vocabulary problem directly: it says users do not need to understand Provider, MCP or Prompt as terms, because in practice they are the source of the AI's brain, the tool connections, and the behavioural instructions.
The scope is narrower than the tagline suggests. The current feature table lists seven tools under AI software configuration (QoderWork CN, TRAE Work CN, WorkBuddy, Grok Build, Codex, Claude Code, OpenCode), while prompt management covers a partly different set (Grok Build, Codex, Claude Code, OpenCode, Gemini, OpenClaw, Hermes), and the memory module covers only OpenClaw and Hermes. That asymmetry is the real story here. FyAgent is not a universal adapter. It is a matrix of per-tool capabilities, and the README is honest enough to say so, noting that support differences are documented in the user manual. Anyone evaluating this should read that matrix before assuming their tool is covered end to end.
How the app reaches into each tool's own files
FyAgent does not sit between you and the model. It edits the configuration that the other tools already read. The README describes a scan step: you open the AI software configuration screen and it scans the machine for installed software. From there you pick one and enter its configuration page, where the app offers entry points for models, Skills, MCP, prompts or authentication, depending on what that tool supports.
The mechanism that matters is the write path. The README states that model and provider changes are previewed before writing, and that results are checked after saving. That preview step is the safety rail for a tool whose whole job is mutating files owned by other programs. The app's own working data defaults to ~/.fyagent on the local machine, so the app keeps its state separate from the configuration it manages.
What the README does not describe is the internal architecture: there is no explanation of how the scanner detects an installation, whether it reads registry entries, known paths or version files, or how a failed write is rolled back. The repository topics include tauri and mcp, and the primary language is Rust, so the desktop shell is presumably Tauri with a Rust core, but the README does not spell out the layering. Treat the scan-and-preview behaviour as documented and the internals as unverified.
Getting it running from a release or from source
The end-user path is a download. The README points to GitHub Releases for the latest installer and lists the artifact names: FyAgent-X.Y.Z-macOS.dmg on macOS, and FyAgent-X.Y.Z-Windows-x64-setup.exe or FyAgent-X.Y.Z-Windows-arm64-setup.exe on Windows. Windows ships an NSIS installer only. The README says explicitly that there is no MSI and no portable ZIP, which rules out silent enterprise deployment and any workflow that expects a drop-in folder.
For developers, the README gives a mise-based flow. You need mise >= 2026.8.6 installed globally, then:
mise trust mise run bootstrap mise run system:check mise run dev
Building for the current system is mise run build, and mise run check is the pre-commit task. The README points to docs/fyagent/development/README.md for the full toolchain and release requirements.
The verification steps are worth quoting in spirit: before installing, read the release notes and check the checksum, signing-status.json and build provenance. The README makes a point that NotSigned describes signing status only and does not by itself prove a file is safe. macOS builds are stated to use Apple Developer ID signing and Apple notarisation. Recent releases are v0.4.4 (2026-09-07), v0.4.3 (2026-09-01) and v0.4.2 (2026-08-20), a cadence of roughly one release every one to three weeks.
The licence is the first thing to check, not the last
FyAgent is source-available, not open source in the OSI sense, and the README says so plainly in its own FAQ. The split is stated in two places: FyAgent's own components and modifications use PolyForm Noncommercial License 1.0.0, and the parts inherited from CC Switch continue under MIT. Commercial use requires separate written authorisation. The repository's licence field reads NOASSERTION, which is consistent with a project carrying more than one licence and a non-standard identifier.
The project history explains the inheritance. FyAgent's predecessor was VibeKey, a physical keyboard plus driver concept, which was later reframed as cross-platform desktop software and renamed. The current desktop application is described as having evolved from CC Switch, with the original authors' copyright and licence notices retained. For anyone doing a licence review, LICENSING.md, LICENSE and THIRD_PARTY_NOTICES.md are the files to read, and the practical question is which files in the tree fall under which licence. The README does not answer that at file granularity, so a commercial adopter would need to do that mapping themselves. This is a description of what the project states, not legal advice.
Where FyAgent is the wrong tool
The README carries its own warning: FyAgent is still in continuous development, and users are told to back up important configuration before upgrading and to read each release's trust statement before installing. A tool that writes into other applications' configuration files, in a project that describes itself as pre-stable, is a combination that deserves caution. The 0.4.x version numbers and the roughly weekly-to-fortnightly release cadence are consistent with that warning rather than in tension with it.
Platform coverage is the second boundary. The badge and the artifact list cover Windows and macOS only. There is no Linux build named in the README. The Windows packaging is NSIS-only, so managed environments that push MSI packages are out of scope without repackaging.
The third boundary is the support matrix itself. Because prompt management and memory editing cover different tool sets than the main configuration screen, a user of, say, Gemini gets prompt management but does not appear in the AI software configuration list. A user of OpenClaw gets prompt and memory editing but likewise is not in the seven-tool configuration list. If your workflow depends on one of those partial integrations, FyAgent covers a slice of it, not the whole thing. The README's own phrasing, that it provides installation, update, launch, authentication and resource allocation entry points "where supported", is doing real work in that sentence.
How it differs from editing dotfiles by hand
The obvious alternative is doing nothing: edit each tool's config file yourself, keep your own notes, and use your shell's history as the audit trail. That approach has real advantages. It has no dependency on a third-party binary, no licence constraint, and no upgrade risk, because nothing is upgrading. The difference in approach is that FyAgent adds discovery and preview. Discovery means you do not have to remember where each of seven tools keeps its provider settings. Preview means you see the change set before it is written, and the README states the app checks the result after saving. Hand-editing gives you neither unless you build it.
The cost is the inverse. With hand-editing, you own the knowledge and nothing can break it. With FyAgent, you gain a single interface but you also gain a component that must track upstream changes in every tool it manages. When Codex or Claude Code changes its configuration format, FyAgent has to follow. The release notes index at docs/release-notes/README.md is where that tracking becomes visible, and it is the thing to watch if you are deciding whether the maintenance burden has been transferred to you or away from you. The README does not make a maintenance commitment either way.
Who should install v0.4.4 and what to confirm first
FyAgent fits a specific profile: a Windows or macOS user running several of the supported tools, comfortable with a source-available licence that forbids commercial use without written permission, and willing to back up configuration before each upgrade as the README instructs. The value proposition is concentrated in the preview-before-write behaviour and in having one screen where models, MCP servers, Skills, prompts and memory are visible together.
It does not fit commercial teams needing clear per-file licence provenance, Linux users, or anyone who needs MSI or portable Windows packaging. It also does not fit someone who wants a stable interface contract, given the project's own development-status note.
Before installing, confirm three things against the repository rather than against this article: the checksum and signing-status.json for the exact release artifact you download, your tool's row in the support matrix in docs/user-manual/en/README.md including which entry points are actually offered, and the licence split documented in LICENSING.md. If your tool appears only under prompt management or only under memory, decide whether that partial coverage is worth a new dependency. If it appears in the configuration list with the entry points you need, the scan-and-preview workflow is the part of FyAgent that earns its place.
Editorial conclusion
Adopt FyAgent if you already run several of the supported tools and want one place to see and edit their model, MCP, prompt and memory settings, and if a noncommercial licence suits you. Do not adopt it if you need commercial use rights, an MSI or portable Windows build, Linux support, or a stable release line, because the README states the project is still in active development and asks you to back up important configuration before upgrading. Verify three things first: the checksum and signing-status.json for the release you download, whether your specific tool appears in the support matrix with the entry points you need rather than a partial set, and the split between PolyForm Noncommercial 1.0.0 and MIT in LICENSING.md and THIRD_PARTY_NOTICES.md.
Community notes