Sharing your .vimrc file will help to reproduce this problem. Thanks!

They are available here and here.

What is the value of :echo g:colors_name, and what happens when you do :execute 'colo' g:colors_name?

Anyway, there's no easy way to find the culprit. I would suggest that you comment out all your plugins and settings except Goyo, and see if the problem is still reproducible. If it's not, you can incrementally uncomment the other settings until you run into the problem.

Same issue here
Executing the first command echo ...: vim tells me there is no such variable
after executing the execute 'colo' etc, colors change.

after executing the second one i ran the first command again
the result was default

@KmBKeef I don't think Goyo works well with 16-color color schemes. Try with 256-color or true-color color schemes.

I had a similar problem where my statusline formatting would be stripped upon exiting Goyo. I'll illustrate here how I fixed it, but I'll preface this by saying that I've only been using Linux for less than 6 months, Vim for less than 2 weeks, and I have 0 experience with programming (or anything of the sort)...so, this is probably not the best way to go about it. Nevertheless it's what I managed to come up with and it seems to work all right.

I had these lines in my vimrc:

hi StatusLine                  ctermfg=8     ctermbg=2     cterm=NONE     guifg=black     guibg=#005F87
set statusline=%<%F		
set statusline+=%M			
set statusline+=%y			
set statusline+=\ Buf:%n          
set statusline+=%=			
set statusline+=\ %{WordCount()}\ words,
set statusline+=\ %l/%L\ %P	

After deactivating Goyo the color would revert to the colorscheme's style. This is what I added to vimrc to rectify the matter:

function! Resetstatusline()  
        setlocal statusline=%<%F%M%y\ Buf:%n=%=\ %{WordCount()}\ words,\ %l/%L\ %P | :hi  StatusLine ctermfg=8 ctermbg=2 cterm=NONE guifg=black guibg=#005F87  
    endfunction

:map <LEADER>G :set go-=m \| :set go-=r \| :Goyo \| :Limelight<cr>
:map <LEADER><LEADER>G :Goyo \| :Limelight! \| :set go+=m \| :set go+=r \| :call Resetstatusline()<cr>

Could ashishtibrewal not do something similar, like map :Goyo! to run Goyo \| :colorscheme X?

When I run :Goyo, it switches my colorscheme to default. Has anyone been able to determine the cause yet?

Not quite the same behaviour, but I've noticed that some elements change their colors.
Before running Goyo:

:Goyo:

:q:

I also do some theming in my vimrc. Couldn't this be prevented with a so $MYVIMRC in the Goyo! command? Don't know if that would have any unintended consequences.

Experiencing the same issue. Using neovim with onedark (256 colors) color scheme. None of the suggested status checks revealed anything weird.

Added the following line as a workaround (ref)
autocmd! User GoyoLeave source $HOME/.vimrc

Would love to see #195 that seems to address this issue merged! (provided people who know more about vimscript than I do think it's a good idea)

I have a similar issue that might be related:
I use bg=light on neovim and when activating via :Goyo and deactivating again (via :Goyo or :Goyo!, doesn't matter) vim reproducably flipps to bg=dark. Maybe this is also the case for the above observed issues?

@nathanshelly

Added the following line as a workaround (ref)
autocmd! User GoyoLeave source $HOME/.vimrc

Tried essentially the same thing but get a long string of errors (E174) related to keymappings. So I'm using this for now:

autocmd! User GoyoLeave silent! source $HOME/.vimrc

I had this issue. My fix (and I think it would be wiped out if I updated the plugin) was to:

1. Navigate to ~/.vim/vim_plug/goyo.vim/autoload/goyo.vim
2. Delete line 340, execute 'colo '. get(g:, 'colors_name', 'default')

I'm guessing that in order for this to be a permanent fix, you guys could just push the deletion of that line into your repo. But, of course, I have no idea what side effects that may cause. I also don't know if this is the right way to solve the problem.

There you go. Hope it was helpful.

I use "vim-nightfly-guicolors", and colo or sourcing did not work.

I confirm that only deleting the execute 'colo '. get(g:, 'colors_name', 'default'), line 340, worked.

It would be nice to delete it upstream or add some check if this is useful for something.

Edit: For those who will come across this issue, I invite you to go and see the PR 195 attached on the side. The solution is more advanced but has not yet been officially validated. In any case it works.