Limit augment to workspaces

[Waino]

Expected behavior

I expected augment.vim to be active only in the workspaces set in g:augment_workspace_folders.

Actual behavior

I was surprised (and not pleasantly) to find that augment.vim was autocompleting in all files opened anywhere, not just limited to the paths I set in g:augment_workspace_folders.

Motivation

For an IDE like vs code, it is reasonable to assume that the software will only be used for programming, and you want autocompletion everywhere. An editor like nvim on the other hand is used for all kinds of files, only some of which relate to the programming projects. This can include sensitive files that the user clearly would not want to send to an API.

Proposed solution

Make the current behavior (autocomplete everywhere) require explicit opt-in by setting a variable, e.g. g:augment_enabled_outside_workspace = v:true. If not set, or set to false, default to only enabling the autocompletion inside the workspaces.

Workaround

Luckily I noticed this before opening any truly sensitive file, and put in place a workaround that requires an env variable USE_AUGMENT to be set before the plugin is loaded. This allows enabling augment per shell session.

call plug#begin('~/.config/.nvim/plugged')
" Augment code completion (conditional on env var)
if !empty($USE_AUGMENT)
    Plug 'augmentcode/augment.vim'
endif
call plug#end()

[alerque]

Absolutely, the current default is a DISASTER. When I first installed the plugin I setup a couple workspaces (specifically FOSS projects so I knew the sources were not sensitive) just to play around with. Then another day I opened up a plain text accounting ledger file. That was an unpleasant surprise. I did NOT consent to every file I opened in my editor being shipped off to a offsite LLM!

[NobbZ]

[I] put in place a workaround that requires an env variable USE_AUGMENT to be set before the plugin is loaded. This allows enabling augment per shell session.

Personally I took this a step further, and use an envvar AUGMENT_WORKSPACE and will load augment only if that is set, and I will use its value to set g:augment_workspace_folders to exactly this one project.

Together with direnv and an .envrc doing export AUGMENT_WORKSPACE=$(pwd) this is something that happens mostly automatic and per project.

[richardhundt]

I came here trying to figure out if indexing is local or remote, since the obfuscated server.js doesn't make it obvious. I guess it's remote then, which is a deal breaker. There's really no reason for it. It's not hard to bundle tree-sitter + chromadb (based on sqlite3) to get local indexing set up. It's bad enough that I have to use someone else's language model.

[mtpauly]

Hi all, thanks for your feedback. To first address @richardhundt 's concern: Augment does construct a remote index of your files for the directories specified in your workspace folders, but our TOS prohibits training on customer code or requests (outside of the community tier where that's very explicit).

In terms of running outside of workspace folders I totally understand your concerns-- we don't do a good job of explaining this in the readme or provide a good configuration option for this behavior. Something we could very easily do is provide a variable like g:augment_only_workspace_folders (need to work on the wording for that) that when set would only provide completions for files within your configured workspace folders. Would that address your concerns?

I'll also update the readme to be more clear about indexing and when the plugin is active.

[Waino]

Hi @mtpauly !

Opt-out with is g:augment_only_workspace_folders clearly better than nothing, but I still think opt-in with g:augment_outside_workspace_folders would be the right choice here. Leaving the default setting shouldn't cause unwanted surprises, and those who want completion everywhere could easily configure it.
I hope you will reconsider changing the default and inverting the flag.