Certain customers may see odd web artifacts on Code UI. Logging out and Logging in resolves this issue.

We are continually monitoring this issue.

This incident has been resolved.

## Summary

On June 8, 2026, a subset of Harness customers experienced UI degradation in the Harness Code Repository module. Affected users saw broken styling — most notably, the Create Repository control was visually impaired and difficult to use. The issue was not a full outage; core functionality remained available

Users who logged out and back in, or opened the application in an incognito/private window, were not affected — pointing to browser-stored state as the failure mechanism.

## Root Cause

Primary cause: A change to the Harness Platform UI framework altered the default theme fallback from a valid, deployable CSS theme to a "system preference" token — a value that instructs the browser to follow the operating system's light/dark mode setting. While this token is valid as a user _preference_, it is not itself a CSS theme: no corresponding stylesheet bundle exists for it. When users without a previously saved theme preference loaded the Harness UI, this unresolvable token was immediately written to their browser's local storage and applied to the page. The result was missing CSS design tokens, which broke the visual rendering of Harness Code.

Because the invalid value was persisted in browser storage, it continued affecting those users across subsequent page navigations until their session was cleared.

‌

## Mitigation

Immediate actions:

The Harness team rolled back the Platform UI to the last known good version on all affected production environments. This stopped new users from hitting the broken default and, once users cleared their session (via logout/login), restored correct rendering.

Affected users were advised to log out and log back in to clear the stale value from browser storage. Opening a new incognito/private window also restored correct behavior immediately.

A targeted fix reverting the default theme to the correct value was merged and deployed. This permanently addressed the root cause without requiring users to take any action.

## Next Steps

The following actions are in progress or planned to prevent recurrence:

‌

• Default theme reverted: The platform UI wrapper now uses a valid, CSS-resolvable theme as the default fallback. `system` preference tokens will no longer be used as raw defaults. (Done)
• Browser storage cleanup: A cleanup was deployed to migrate any stale invalid theme values already persisted in affected users' browsers, resolving the issue without requiring manual logout. (Done)
• Defensive validation in the theme provider: Adding input validation so that any theme value — whether loaded from storage or applied as a default — is checked against the set of known valid CSS themes before being written to storage or applied to the DOM. Invalid values will fall back safely to a known-good theme.
• Expanded test coverage: Adding automated end-to-end tests that exercise the theme initialization path for users across both the new and legacy UI experiences, including first-time users with no previously saved preference.
• Client-side monitoring for theme resolution failures: Adding telemetry to detect when an invalid theme value is applied, enabling the team to catch styling regressions before they are reported by customers.