Convenience creates a credential store outside the organization's usual controls
Developer tools — CLIs, IDE plugins, local scripts — routinely cache authentication tokens locally so a developer isn't re-authenticating on every single command. This is a genuine convenience, and it also means credentials with real access to real systems now live somewhere the organization typically has far less visibility into, and far less control over, than any server it directly operates.
A developer's own machine is, in most organizations, a considerably softer target than a hardened production server — subject to personal browsing, third-party software, and physical loss in a way production infrastructure generally isn't. Credentials cached there inherit that weaker protection without necessarily being scoped or monitored any differently than credentials living on infrastructure the organization controls directly.
Scoping and lifetime as the practical mitigations
Because the endpoint itself is harder to fully secure, the more tractable levers are what a locally cached credential can actually do and how long it remains valid: narrowly scoped tokens tied to a specific tool's actual needs, and short lifetimes that limit how much a compromised laptop actually hands over even in the worst case. Neither eliminates the risk; both bound what a single compromised developer machine is worth to an attacker.