SAFE CLI subcommand suggestions: reset and uninstall

It would be helpful if I could simply run safe uninstall and have all vault data, preferences, and other files written to the filesystem throughout using SAFE removed along with the binaries. (safe-cli, safe-authd, safe-vault)

A useful counterpart to that subcommand would reset state without removing the binaries.


Nice suggestions. I’ve added a couple of separate issues for these:

  1. Add uninstall command
  2. Add reset command

/cc @bochaco, @joshuef, @dirvine,

As the reset and uninstall subcommands will modify and potentially delete user data, what expectations would you have of the implementations?

hmmmm, good Q.

I’d expect uninstall to warn what it will delete at a prompt (which coudl be overriden by a flag). Perhaps a confirmation therafter depending on how strongly worded/informative we want the warning to be.

As far as I know, we’re aiming to have installs of CLI based things/ config and apps to be in ~/.safe dir generally. So it should most likely be just removing that…

I’m not sure if it would/should attempt to detect other apps (eg browser). Even if it did eventually, i’d certainly not expect it in an initial impl.

I wonder if it needs to be a “secure” delete? Overwriting a few times (or that can be an option later… i’m also not sure how much that increases security)

That’s off the top of my head.

“Reset” is likely looking to setup as a clean install and not remove the installed apps just user data?



Thank you for your helpful reply.

uninstall will likely build atop reset in some fashion so I’ll begin with reset. I’ll address your important question of detecting other Safe apps, such as the browser, at that time.

Regarding reset and the deletion of local user data, as I don’t yet know what all is persisted locally, would it be permanently destructive of more than configuration and preference files? I’m assuming it wouldn’t affect user data stored in Safe in any way, and wallets could be reinitialized by simply authenticating with the user’s keys.

Optional secure delete is a great idea and I suspect we could leverage OS API for it on some platforms. I’ll get the basic reset functionality in place first and then revisit it.



Please change the title of this thread to “SAFE CLI subcommand suggestions: reset and uninstall”.

1 Like

safe reset will revert all local file and directory creation made by Safe. To revert, all points of file and directory creation, of any repo of, must be cataloged.

To build the catalogue, I’ll search the repos for the use of any API known to create files or directories. API known to create files or directories:

  • std::fs::DirBuilder::create
  • std::fs::File::create
  • std::fs::File::with_options
  • std::fs::OpenOptions::create
  • std::fs::OpenOptions::create_new
  • std::fs::OpenOptions::open
  • std::fs::copy
  • std::fs::create_dir
  • std::fs::create_dir_all
  • std::fs::hard_link
  • std::fs::soft_link
  • std::fs::write

If you know of others in use in Safe repos, please reply with a link to a line of code.

Just use diff

I could diff my FS before and after some Safe usage, however it’s likely that it wouldn’t reveal all, especially lazily-created, files and directories. The better place to run diff checking is on test/CD/CI infrastructure as that should exercise the codebase more than any other, and therefore reveal lazily-created files and directories.


The initial scope of this implementation will revert only file and directory creation in Safe’s repos. A complete catalogue would require that the entire dependency graph of Safe’s crates be searched.

safe reset is prone to becoming stale over time as code using file and directory creation API is added. I’d appreciate anyone’s ideas for maintaining safe reset's consistency with the codebase, preferably without manual developer intervention. My current best idea is for a test/CD/CI diff task comparing diff results with a file and directory creation ‘manifest’ config file which lists the files and directories safe reset deletes.

1 Like

It shouldnt affect data on safe. Locally we’re persisting CLI auth, eg. But you can get that again via logging in. So you should be fine there.

cc @lionel.faber @bochaco, not sure if you have any ideas of other file locations beyond tmp and ~/.safe we’re using at the mo? I know the drive is for all things in ~/.safe but just to be sure…



IMHO hard-coded paths is outdated. Well-formed programs targetting *nix OSs should adhere to with more details and examples at Not only would that respect common conventions, it would also respect a user’s orderly FS layout preferences. In my experience with *BSD and Linux it works very well.

Perhaps I could add that in the future.

We used to use XDG and changed it for storing things under ~/.safe/, which other apps also do. This way showed it was way simpler and easier for users to find and know what apps are storing, and it’s consistent across platforns. XDG is a bit confusing when it comes to diff platforms, also IIRC data and config of an app go to completelly diff folders paths. This is a personal comment and how I see it for testing though, for sure we should adhere to standards in the future if that’s found better, but again some other apps took this path too like git or cargo i think.



Is there an example of any other subcommand that prompts the user similarly to how safe reset will need to prompt the user for confirmation?

1 Like

Draft ready WIP: feat(cli): implements 'safe reset' subcommand.

1 Like

Sorry @latch, totally missed your prev Q. Will have a look today at the draft!


1 Like