Reported issues for Radar

Radar Diagnostics

Version: k8s-ui-v1.9.0-3-g70037c9d-dirty | Go: go1.26.5 | OS: linux/amd64 | Uptime: 11s

Connection

• State: connected
• Context: `gke_ayoconnect-central-apigee_asia-southeast2_kong-apigat

Read the thread · 2026-08-05 · open · external user · 4 comments

feat: add Kubecost REST API support for cost data

Problem statement

Radar's cost view requires Prometheus metrics emitted by OpenCost or Kubecost. Kubecost Enterprise 3.x in federated mode does not emit Prometheus metrics at all — cost data flows from the finopsagent to S3, then to the aggregator, which exposes it only via REST API. Clusters running this setup see:

Cost metrics not found — Prometheus is available, but no OpenCost or Kubecost metrics were detected

There is no workaround: the metrics do not exist in Prometheus, so poi

Read the thread · 2026-06-29 · open · external user · 3 comments

radar-desktop fails to run on Fedora 43 KDE

Describe the bug

The radar-desktop app (v1.4.4) doesn't run on Fedora 43 (KDE Edition) running Wayland.

To reproduce

Steps to reproduce the behavior:

1. Launch radar-desktop after installing the RPM
2. There is a brief window (black) that appears and then disappears on screen
3. The output on the console is:

2026/04/14 22:10:17 Radar Desktop 1.4.4 starting...
2026/04/14 22:10:18 PATH enriched from login shell (6 entries)
2026/04/14 22:10:18 KUBECONFIG enrichment skipped: not found 

[Read the thread](https://github.com/skyhook-io/radar/issues/465) · 2026-04-14 · closed · external user · 3 comments

### Skip ssl check

## Problem statement
Error tls checking:

OIDC initialization failed (issuer=https://keycloak.local/auth/realms/infra-devops): Get "https://keycloak..local/auth/realms/devops/.well-known/openid-configuration": tls: failed to verify certificate: x509: certificate signed by unknown authority — cannot start with auth-mode=oidc 

## Proposed solution

Add --skip-tls options for skip ssl check 

## Alternatives considered

Add documentation for skiping ssl checking

## Additional context

│ 2026/04/0

[Read the thread](https://github.com/skyhook-io/radar/issues/410) · 2026-04-02 · closed · external user · 1 comment

### Enable MCP in the Desktop App

The title says it all. 
Allow MCP to be enabled in the desktop app

[Read the thread](https://github.com/skyhook-io/radar/issues/308) · 2026-03-11 · closed · external user · 1 comment

### YAML Edit Save option is not working and also it was good to have Scale Up and Down option in previous versions.

## Describe the bug

<!-- A clear and concise description of what the bug is. -->

## To reproduce

<!-- Steps to reproduce the behavior -->

## Expected behavior

<!-- What you expected to happen -->

## Diagnostics

<details><summary>Diagnostics snapshot</summary>

## Radar Diagnostics

**Version:** 1.1.1 | **Go:** go1.26.1 | **OS:** darwin/arm64 | **Uptime:** 6h44m24s

### Connection
- State: `connected`
- Context: `arn:aws:eks:eu-central-1:565269690401:cluster/unosecur-non-prod-cluster`
- Cl

[Read the thread](https://github.com/skyhook-io/radar/issues/295) · 2026-03-10 · closed · external user · 2 comments

### Slow connection to large cluster

## Describe the bug

Using Radar 1.0.3

Very slow connection to large cluster. On my case the cluster has:
- 400 namespaces
- 18000 pods
- 12000 services and ingreses
It takes about 28 minutes to connect to the cluster and get the resources. 
I am also using FreeLens and that is able to do it in about 10s

## To reproduce

Given that one has a cluster of that size

1. Run 'kubectl radar'
2. Wait ~28 minutes
3. Eventually see the cluster resources

## Expected behavior

I would expect one of:
1. 

[Read the thread](https://github.com/skyhook-io/radar/issues/244) · 2026-03-03 · closed · external user · 12 comments

### can't connect despite working k8s context

To be honest I'm not really sure what exactly is radar trying to do to connect to the cluster.
I'd expect that if kubectl has no issues then radar shouldn't have issues too.

But somehow it fails:

us-iad-fenio-test: ~$ kubectl get pod No resources found in default namespace. us-iad-fenio-test: ~$ kubectl radar 2026/02/01 17:38:12 Radar 0.7.6 starting... 2026/02/01 17:38:12 Using in-cluster config

✗ Cluster authentication failed

Your cluster credentials may have expired or are invalid.

Read the thread · 2026-02-01 · closed · external user · 1 comment

Most recent

Expose more data to mcp

Problem statement

I really hate needing to copy paste / give a browser to the ai so it can get access to open cost data and rightsizing

Proposed solution

Expose those data trough the mcp server

Alternatives considered

giving a browser to the ai but more token usage and cant run headless

Read the thread · 2026-08-28 · open · external user · 0 comments

AI diagnose (cursor-agent): all MCP tool calls rejected — COULDN'T DETERMINE

Describe the bug

Radar AI diagnose with Cursor Agent fails with COULDN'T DETERMINE. Every Radar MCP tool call (get_resource, get_events, get_pod_logs, get_neighborhood, etc.) is marked rejected: "All the MCP tool calls were rejected by the user."

The ephemeral workspace already approves the radar MCP server (mcp-approvals.json contains a radar-… entry). The failure is Cursor auto-denying tool invocations in headless -p mode when Radar passes --trust instead o

Read the thread · 2026-08-28 · open · external user · 0 comments

Support OAuth 2.1 authentication for remote MCP clients

Problem

Radar's self-hosted OIDC authentication protects /mcp with a Radar browser session cookie, but remote MCP clients such as OpenCode follow the MCP OAuth discovery flow after receiving 401.

Radar currently returns:

• 401 from /mcp
• 404 from /.well-known/oauth-protected-resource/mcp

As a result, remote MCP clients cannot authenticate or refresh credentials against a self-hosted Radar deployment.

Requested behavior

Add MCP-compatible OAuth 2.1 support for self-hosted

Read the thread · 2026-08-14 · open · external user · 1 comment

running radar locally with mutliple kubeconfigs and mcp

Describe the bug

not sure if this is a bug or not. but when running radar on you local system with the mcp server enabled, and multiple kubeconfigs set the LLM says it only has access to one cluster, while we can switch between the clusters in the UI, this doesn't update what the MCP has access to

To reproduce

Steps to reproduce the behavior:

1. set the KUBECONFIG to point to multiple clusters.
2. from the same shell start Radar
3. use your tooling of choice to access your llm and ac

Read the thread · 2026-07-05 · open · external user · 1 comment

feat(auth): per-user API keys for programmatic access (MCP, CI, headless clients)

Problem

When Radar runs with --auth-mode=oidc, headless clients — MCP tools, CI pipelines, automation scripts — cannot authenticate because they cannot complete the browser-based OIDC login flow. The only current workaround is manually minting a raw radar_session cookie using the HMAC secret, which is fragile, not user-scoped, and bypasses any per-user RBAC.

Proposed Solution

Add a /api/auth/api-keys endpoint that lets authenticated users generate long-lived API keys tied to their

Read the thread · 2026-05-19 · open · external user · 0 comments

v1.5.14: README "Supported Resources" lists PV/StorageClass/VPA/Gateway/HTTPRoute/NetworkPolicy/PDB/SA/LimitRange but capabilities map reports them off

Summary

Several resource kinds listed in the README "Supported Resources" table are present at the RBAC layer (via rbac.additionalRules or the chart's default ClusterRole) but are not rendered by the v1.5.14 binary — the frontend capabilities.resources map reports them as false, and MCP list_resources returns errors specific to the missing type handlers.

This affects:

| README Category | Kind | Behaviour in v1.5.14 | |---|-

Read the thread · 2026-05-13 · closed · external user · 0 comments

Cannot hide secrets from users when auth.mode is oidc

Problem statement

With auth.mode: oidc, the chart always grants secrets access to the ServiceAccount regardless of rbac.secrets: false. All authenticated users can see secrets in the resource browser — even if their personal ClusterRole doesn't include secrets.

I created a custom ClusterRole (radar-viewer) that explicitly excludes secrets and bound it to my Keycloak group via ClusterRoleBinding, but users in that group still see secrets in the UI.

There's no way to hide secrets from

Read the thread · 2026-05-12 · closed · external user · 0 comments

Support loading OIDC client secret from existing K8s Secret

Currently the OIDC client secret is passed as a Helm value (auth.oidc.clientSecret), which means it's visible in Helm release history.

We already support auth.existingSecret / auth.existingSecretKey for the session signing key (HMAC), but not for the OIDC client secret itself.

Request: Allow referencing a K8s Secret for the OIDC client secret, e.g.:

auth:
  oidc:
    existingSecret: radar-oidc-credentials
    clientSecretKey: client-secret

Also update the auth docs to m

Read the thread · 2026-03-30 · closed · outside contributor · 0 comments

Flag for disabling MCP in Helm

Especially when radar is hosted and behind authentication, it's hard to reach the MCP, so it would be nice if there was a Helm value that allows disabling it.

Read the thread · 2026-02-18 · closed · outside contributor · 0 comments

The remaining reports are on the project's issue tracker.