Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/dot-ai/issues.md or /mcp/dot-ai/issues.json, or Pod over MCP.

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.

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 · 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) can only be distributed via git submodules, which is a completely separate mechanism from the s

Read the thread · 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 · 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:

Read the thread · 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. This enables browser-based login via

Read the thread · 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 · 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 · 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?

Read the thread · 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:

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

`src/tool

Read the thread · 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:

Read the thread · 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 · 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 · 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 · 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 · 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 · 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 · 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):

{{- 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).