# Reported issues for dot-ai

Pod holds 20 of 66 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [dot-ai](/mcp/dot-ai).

## Most discussed

### [Feature]: Dynamic URL for major AI llm service endpoints

### Problem Statement

I want to be able to link internal/self hosted llm models serviced on k8s via a clusterIP service (and its related URL) when installing the helm chart rather than the public available services. It would be great to be able to submit URL service endpoint (http or https) and the related AI token. The token can be optional as sometimes internal test service may not have authentication. The reason is requirement for closed/retricted AI llm engines due to governance/compliance 

[Read the thread](https://github.com/vfarcic/dot-ai/issues/193) · 2025-10-27 · closed · external user · 25 comments

### feat: serve folder-based skills (with scripts/manifests) from git repositories

## Problem

The server can serve **user-defined prompts** from a git repository (`DOT_AI_USER_PROMPTS_REPO`), but only as **flat `.md` files**. Meanwhile, real-world skills are **folder-based** — a directory containing `SKILL.md` plus supporting files like shell scripts, manifests, templates, etc.

Today, folder-based skills (like those in [dot-ai-skills](https://github.com/vfarcic/dot-ai-skills)) can only be distributed via **git submodules**, which is a completely separate mechanism from the s

[Read the thread](https://github.com/vfarcic/dot-ai/issues/379) · 2026-02-17 · closed · external user · 9 comments

### Feature Request: Git-Sync Support for Custom Prompts from Private/Public Repositories

## Summary
Add native support for syncing custom prompts from git repositories (both public and private) with authentication, allowing users to maintain their prompt libraries in version control and automatically inject them into the dot-ai MCP server.

## Motivation
Currently, users who want to use custom prompts with dot-ai need to manually manage prompt files or create custom deployment configurations. Organizations often want to:

1. **Version control their prompts** - Track changes, collabo

[Read the thread](https://github.com/vfarcic/dot-ai/issues/164) · 2025-10-13 · closed · external user · 9 comments

### feat: expose user-defined prompts force-refresh mechanism

## Problem

User-defined prompts loaded from git repositories (via `DOT_AI_USER_PROMPTS_REPO`) are cached with a TTL (`DOT_AI_USER_PROMPTS_CACHE_TTL`). When prompts are updated in the git repo, users must either:

1. Wait for the cache TTL to expire, or
2. Restart the pod/process

There is **no way for a user to trigger an on-demand refresh** of the prompts cache.

## Context

The internal plumbing for force-refresh **already exists** but is never exposed to users:

- `ensureRepository()` in `sr

[Read the thread](https://github.com/vfarcic/dot-ai/issues/378) · 2026-02-17 · closed · external user · 5 comments

### PRD: User Authentication & Access Control

## PRD: User Authentication & Access Control

**Problem**: The MCP server currently only supports a single shared auth token for all users, preventing enterprise deployments where individual user identity needs to be verified and tracked for access control and audit purposes.

**Solution**: Implement **OAuth 2.1-based authentication** following the [MCP Authorization Specification](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization). This enables browser-based login via

[Read the thread](https://github.com/vfarcic/dot-ai/issues/360) · 2026-01-30 · closed · 5 comments

### pushToGit: support Pull Request workflow for GitOps (branch + PR instead of direct push)

## Context

Hi @vfarcic ! 
cc: @reysylaj 
We are deploying dot-ai on AWS EKS landing zone clusters as a shared platform service. Authentication is via Dex OIDC (GitHub SSO), RBAC is enforced, and the AI provider is Amazon Bedrock via EKS Pod Identity.

Our landing zone GitOps repositories follow a strict convention. dot-ai needs to push generated Crossplane claim manifests there, but the current `pushToGit` behavior does not match our operational requirements.

## The problem

`pushToGit` in v1.

[Read the thread](https://github.com/vfarcic/dot-ai/issues/710) · 2026-07-30 · closed · 3 comments

### feat(mcp-client): support authentication headers for outbound MCP server connections

### Problem

dot-ai's MCP client cannot authenticate to MCP servers that require authorization. The `mcpServers` Helm configuration supports `endpoint` and `attachTo`, but `connectAndDiscover()` creates `StreamableHTTPClientTransport` without passing `authProvider` or `requestInit`, so all outbound MCP connections are unauthenticated.

PR #410 explicitly scoped this out as "in-cluster trust model." This works when all MCP servers run in the same cluster without auth, but breaks for MCP servers b

[Read the thread](https://github.com/vfarcic/dot-ai/issues/414) · 2026-03-26 · closed · outside contributor · 3 comments

### [Feature]: Support MCP Sampling to use Host LLM

### Problem Statement

The primary motivation is wasted cost. One may already have an active subscription on OpenAI, Claude, or Gemini (or any other service), but with this MCP, to use advanced features, a separate API key is required, which often incurs additional costs on top of the subscription. Local LLM models are adequate, but usually are worse in comparison to external models.

### Who is affected by this problem?

- [x] End users
- [ ] Developers/contributors
- [ ] Platform engineers/ope

[Read the thread](https://github.com/vfarcic/dot-ai/issues/279) · 2025-12-15 · closed · 3 comments

## Most recent

### remediate says "Automatic validation has been completed" alongside a payload saying validation could not be completed

Pre-existing bug, observed during the review of #716 (PRD #710) and deliberately preserved rather than silently changed. Line numbers as of `0045b84`.

## What is wrong

When post-execution validation **fails**, remediate tells the caller that validation **completed**, in the same response that carries a validation payload saying it could not.

`src/tools/remediate.ts:921`, inside the next-steps list:

```ts
'Automatic validation has been completed - see validation results above',
```

`src/tool

[Read the thread](https://github.com/vfarcic/dot-ai/issues/732) · 2026-08-06 · open · 2 comments

### Prompts ?repo= SSRF narrowing covers IP literals only — a hostname that resolves to an internal address still reaches the clone

Known, documented gap from #716 (PRD #710), filed so it is tracked rather than only described in a code comment. Line numbers as of `0045b84` on the #716 branch — this validation does not exist on `main` yet.

## What is wrong

#716 narrowed the prompts `?repo=` override so it refuses non-public **IP literals** before anything is cloned, with `HTTP 400 VALIDATION_ERROR`:

- IPv4: `127.0.0.0/8`, `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `169.254.0.0/16` (link-local, including the cloud met

[Read the thread](https://github.com/vfarcic/dot-ai/issues/729) · 2026-08-06 · open · 0 comments

### MCP progress: make heartbeat abort-aware and scope the progress reporter per tool call

Two follow-ups deliberately left out of #708 (PRD #705). Neither is a live bug; both are robustness cleanups on the progress-notification plumbing added there.

## 1. The heartbeat ignores `extra.signal`

`startProgressHeartbeat` (`src/interfaces/request-context.ts`) fires on a fixed interval until the tool handler returns. It never observes the request's abort signal, so after a client disconnects the SSE stream is gone and **every subsequent tick rejects and logs at `warn`** for the remainder 

[Read the thread](https://github.com/vfarcic/dot-ai/issues/713) · 2026-08-05 · open · 0 comments

### MCP progress notifications for long-running tools

## PRD: MCP Progress Notifications for Long-Running Tools

**Problem**: dot-ai emits nothing for the duration of an MCP tool call. Behind a load balancer with an idle timeout, long `recommend` calls get their connection dropped and fail on the client even though the server completes the work. Reported in #704.

**Solution**: Emit MCP `notifications/progress` for the duration of every MCP tool call, driven by a time-based heartbeat bound into the existing request-scoped `AsyncLocalStorage`. No-op

[Read the thread](https://github.com/vfarcic/dot-ai/issues/705) · 2026-07-28 · open · 0 comments

### [Feature]: server-side ingestion endpoint for CLI-uploaded skill sources (companion to dot-ai-cli#13)

## PRD: Server-Side Ingestion Endpoint for CLI-Uploaded Skill Sources

**Problem**: All skill sources are fetched server-side today (`?repo=` → the server clones). That assumes the server can both reach and authenticate to the source. After #621 (per-request token) that holds for any source reachable with a *static* credential — but it still breaks for sources the server fundamentally cannot reach or authenticate to (SSO/OIDC/device-attested VPNs, managed/hardened clusters with no egress path or

[Read the thread](https://github.com/vfarcic/dot-ai/issues/647) · 2026-06-16 · closed · 1 comment

### Evaluate SDK MCP client for consuming external MCP tool servers

## PRD: Evaluate SDK MCP Client for External Tool Servers

**Problem**: dot-ai is an MCP server but cannot consume tools from other MCP servers. The SDK has experimental_createMCPClient for this.

**Solution**: Evaluate whether consuming external MCP servers as tool sources would enable useful integrations (e.g., connecting to external monitoring or CI/CD MCP servers).

**Detailed PRD**: See [prds/463-evaluate-sdk-mcp-client.md](https://github.com/vfarcic/dot-ai/blob/main/prds/463-evaluate-sdk-m

[Read the thread](https://github.com/vfarcic/dot-ai/issues/463) · 2026-04-11 · open · 0 comments

### Evaluate streamText for long-running operations (REST/CLI)

## PRD: Evaluate streamText for Long-Running Operations (REST/CLI)

**Problem**: All AI generation uses blocking generateText. On the REST and CLI paths there is no mechanism to surface intermediate output, so users get no feedback until completion.

**Solution**: Evaluate where streamText with onStepFinish could provide real-time progress for CLI and REST API paths.

**Scope correction**: this PRD previously stated that MCP "doesn't support streaming tool responses" and scoped MCP out entirely.

[Read the thread](https://github.com/vfarcic/dot-ai/issues/455) · 2026-04-11 · open · 0 comments

### RBAC enforcement gaps when deploying to multi-tenant clusters

## Problem

When deploying to Kubernetes clusters with RBAC enabled, the AI agent currently lacks fine-grained authorization checks before executing tool operations. This creates two gaps:

1. **No pre-flight validation**: The agent doesn't verify user/service account permissions against cluster RBAC policies before recommending or executing deployments. It discovers resources the user cannot actually access and suggests modifications anyway.

2. **No tool-level gating**: Operations like `kubect

[Read the thread](https://github.com/vfarcic/dot-ai/issues/397) · 2026-03-07 · closed · external user · 2 comments

### dot-ai 1.6.0 crashes when ingress.tls.enabled=false: Issuer URL must be HTTPS

## Problem

Upgrading from dot-ai 1.5.0 (chart 0.58.0) to 1.6.0 (chart 0.59.0) causes a crash loop when `ingress.tls.enabled` is `false`:

```
Failed to start DevOps AI Toolkit MCP server: Error: Issuer URL must be HTTPS
```

## Root Cause

Chart 0.59.0 adds Dex as a new sub-chart, **enabled by default**. The `DEX_ISSUER_URL` env var is derived in `_helpers.tpl` (`dot-ai.dexExternalUrl`):

```go
{{- if or .Values.ingress.tls.enabled .Values.gateway.listeners.https.hostname -}}
https://{{ $host }

[Read the thread](https://github.com/vfarcic/dot-ai/issues/396) · 2026-03-05 · closed · external user · 1 comment

### Kubernetes RBAC Enforcement for Tool-Level Authorization

## PRD: Kubernetes RBAC Enforcement

**Problem**: All authenticated users (OAuth and static token) currently have full access to all tools. There is no way to restrict which tools a user can execute or limit access to specific namespaces.

**Solution**: Enforce tool-level and namespace-level permissions using Kubernetes SubjectAccessReview with a virtual API group (`dot-ai.devopstoolkit.ai`). Ship pre-built ClusterRoles and include audit logging of authorization decisions.

**Detailed PRD**: See

[Read the thread](https://github.com/vfarcic/dot-ai/issues/392) · 2026-03-02 · closed · 0 comments

### GitOps-friendly usage: recommended approach when cluster modifications should only happen via Git PRs?

## Use Case

We're evaluating dot-ai for a **GitOps-based platform** where:
- Crossplane Compositions (XSQL, XApp, XEnvironment) are installed in the cluster
- All cluster modifications must go through Git PRs (ArgoCD/Flux)
- Developers use VS Code with GitHub Copilot as their AI client

We want dot-ai to:
1. **Discover** our Crossplane capabilities (via CapabilityScan)
2. **Generate** Crossplane Claim manifests based on user intent ("create a postgres database")
3. **Output** the YAML to the us

[Read the thread](https://github.com/vfarcic/dot-ai/issues/389) · 2026-02-27 · closed · 2 comments

### PRD: Auth-Agnostic Identity & Kubernetes RBAC

## PRD: Auth-Agnostic Identity & Kubernetes RBAC

**Problem**: Enterprise deployments need user-level authentication and authorization. Current system has a single shared token with no individual identity, no access control, and no audit trail.

**Solution**: Unified gateway (Envoy AI Gateway — open source, CNCF) handles OAuth for both MCP and HTTP protocols. dot-ai is auth-agnostic — it only reads identity headers from the gateway and enforces authorization via Kubernetes RBAC (SubjectAccessRev

[Read the thread](https://github.com/vfarcic/dot-ai/issues/380) · 2026-02-18 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/vfarcic/dot-ai/issues).