Fossil doesn't store the password in the same place as remote-url, so it's not surprising that simply setting the remote URL doesn't always set the password as well.

Try giving the remote-url command without the :password bit and see if it prompts for a password in that case. If it does, then it'll update the password properly.

If the problem you're trying to solve is being able to switch the password via remote-url without answering a yes/no prompt, see the code for the new fossil clone --save-http-password feature. It should be simple to port that over to work with remote-url as well.

As for the discrepancy between Windows and non-Windows, yes, there are ifdef'd differences in those code paths, because Windows doesn't have a built-in getpass() function, so we have to do things differently on Windows. Doubtless the two ifdef cases aren't step-by-step identical. It's probably pretty simple to fix for someone with a Windows Fossil build environment set up.

Try giving the remote-url command without the :password bit and see if it prompts for a password in that case. If it does, then it'll update the password properly.

This is how I've always done it on Windows 10 with Fossil 2.9. I simply enter the password when prompted, enter 'y' to remember, and have had no issues. This is both with an initial clone, and after entering the fossil remote-url command.

I view it as bad practice to enter a password anyplace where it is visible in plain text, such as in the command history. So I never put it in unless prompted.

Are you running the build of Fossil 2.9 from the Fossil web site, or a custom build?

From the website

Leave off the colon. You're telling Fossil that the password is empty by including it. You want Fossil to prompt you for it interactively instead.

Yup. That's what I expected. If I leave off the colon then I get an error.

If you add the --httptrace option to the command, do you get one or more "http-request-" and "http-reply-" files left over in your local directory? Those file contain the raw HTTP request and reply, and might contain your unencrypted password or other sensitive information, so you probably should avoid posting them here. But you can look at them and see if the error is coming from the server, and if so, perhaps get a clue as to its cause.

FWIW, I am unable to reproduce your problem with generic cloud-based Fossil servers, though I haven't tried chiselapp specifically. Perhaps this has something to do with chiselapp - I don't know...

running in a cygwin session. I am running a version of fossil downloaded from the website.

Have you tried from a regular cmd window or from a powershell window?

I always had issue when using native windows fossil.exe under Cygwin or vice-versa.

If you want to use Cygwin, it’s better to use a Cygwin compiled fossil executable.

If msys is enough for you, the native windows executable will works just fine in a Msys shell.

+1: The Cygwin terminal I/O code is written with the assumption that it's working with programs using the I/O code in cygwin1.dll, and while it tries to work with native Windows executables directly making use of the Windows console APIs as well, it can fail to give expected output in that case.

Since fixing those problems with native executables would break Cygwin apps correctly using cygwin1.dll, requests for such fixes were always rejected during the years I participated on the Cygwin mailing lists. I assume that stance hasn't changed since I left.

Fossil is shipped in the Cygwin package repo, and as of this writing, they're shipping 2.9 as the latest version.

Not only will using the Cygwin build of Fossil solve your terminal output problems, it'll let you use POSIX paths, and it may have other ancillary benefits.