You Changed the Proxy Password. One Build Still Has the Old Copy.

The new password works in the browser. Project A builds. Project B returns 407. The proxy does not have to be choosing randomly: one of its clients may still be presenting an old credential.

Follow consumers, not just files

A project-specific properties file can differ from the user default. An environment value can be captured when a launcher starts. A credential helper can have its own stored entry. None is updated simply because another application accepted the new password.

Make a short inventory of the consumers that actually use the account: interactive tools, build services, scheduled tasks and application clients. For each, record where the value comes from and when it is read. Keep the value itself out of the inventory.

Compare the failed process with the working one

Check the account, working directory, selected configuration and credential source. Two projects with similar dependencies can use different local files. A long-running agent can retain input from before the rotation even after a new terminal sees the updated environment.

Use a deliberate restart or documented configuration refresh only where that client needs one. Restarting everything at once hides which consumer was stale and can interrupt unrelated work.

Do not confuse client refresh with revocation

Updating clients and making old credentials unusable are separate operations. A proxy can have authentication caching, and an established connection may have a lifecycle different from the password file. Follow the operator's revocation policy rather than assuming one successful request proves the old account material has disappeared.

For the next rotation, make the consumer list part of the change. A successful outcome is each intended client using its intended source and account—not merely the password dialog closing on one workstation.