004 / hfm
A Hugging Face manager
One CLI and one MCP server for every Hugging Face account, repo and Space — built for humans and agents alike.
Measured, not marketed
- 2
- dependenciestyper and requests
- ~8 h
- OAuth token lifetimerefreshed automatically
- 0600
- token file permissionsstored locally, never in dotfiles
- 9
- MCP toolsfive write tools, gated by --read-only
01Auth that does not paste tokens into dotfiles
hfm uses Hugging Face's native OAuth device flow. You register a public OAuth app once, link accounts by name, and the access and refresh tokens land in ~/.config/hfm/tokens.json with 0600 permissions. Short-lived access tokens are refreshed automatically, so the operator never handles a token by hand.
Multiple accounts are first-class: a default plus named ones, each with its own scopes and its own token, selected per command with -a.
02One CLI for accounts, repos and Spaces
List and inspect repos, create them, upload files or folders, download, move or rename, and set Space secrets from a prompt rather than the shell history. The commands map to the operations people actually repeat, not to the entire Hub API.
03The same operations, to an agent
hfm mcp runs an MCP server over stdio, exposing the read tools by default and the write tools unless --read-only is set. delete_repo is not registered at all unless HFM_ALLOW_DESTRUCTIVE=1.
Every agent-triggered call is appended to an audit log as one JSON line — tool, account, arguments, timestamp — so an agent's actions are reviewable after the fact rather than inferred.
—What it does not do
- Device-flow OAuth means you create and register your own public OAuth app; hfm does not ship a shared client ID.
- Removing an account locally drops the tokens, but server-side access ends only when you revoke the app in Hugging Face settings.
- Deliberately only two dependencies, which also means the Hub surface beyond the implemented commands is out of reach.