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/mcp-mayankmahavar1mg/issues.md or /mcp/mcp-mayankmahavar1mg/issues.json, or Pod over MCP.

Reported issues for mcp

Pod holds 13 of 13 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 mcp.

Most discussed

setMetaData fails with standard metadata objects, requires undocumented array of JSX elements

Current Documentation

Returning an object from setMetaData like { title: '...', meta: [...] } causes rendering/parsing errors or fails silently in the HTML template output. It actually requires returning an array of React JSX elements: [ <title key="title">...</title>, ... ].

Suggested Documentation

We expect setMetaData to support standard metadata configuration objects, or for the documentation/types to explicitly clarify that it expects an array of JSX elements to avoid devel

Read the thread · 2026-07-09 · closed · 2 comments

Android build fails on SDK Platform 34 installation with FileAlreadyExistsException and missing global Java Runtime

Preflight Checklist

Steps to Reproduce

  1. Ensure there is a corrupted temp download or platform directory for Android-34 under ~/Library/Android/sdk/.temp/ or ~/Library/Android/sdk/platforms/android-34
  2. Ensure no global Java Runtime is configured on the syst

Read the thread · 2026-07-09 · open · 1 comment

catalyst-mcp crashes with ERR_DLOPEN_FAILED (better-sqlite3 NODE_MODULE_VERSION mismatch)

Preflight Checklist

Steps to Reproduce

  1. Install better-sqlite3 or catalyst-core using Node 22.
  2. Configure catalyst-mcp server to run under Node 20.4.0.
  3. Start/initialize catalyst-mcp server.

Expected Behavior

The catalyst-mcp server should initializ

Read the thread · 2026-07-07 · open · 1 comment

Clarify which IPs to change in config.json; default 127.0.0.1 is correct for the simulator

Summary

config.json has three IP-shaped settings — NODE_SERVER_HOSTNAME, WEBPACK_DEV_SERVER_HOSTNAME, and WEBVIEW_CONFIG.LOCAL_IP — and the relationship between them isn't documented anywhere I could find. The default for all three is 127.0.0.1 and that's correct for the iOS simulator (which shares the Mac's loopback). The only one that needs to change to a LAN IP is WEBVIEW_CONFIG.LOCAL_IP, and only when targeting a physical iOS/Android device on the same Wi-Fi.

Failure mo

Read the thread · 2026-05-03 · open · 1 comment

useFilePicker accessor surface is unclear in docs; consumers reach for raw data

Summary

useFilePicker returns multiple ways to read picked files — data, selectedFile, selectedFiles, getFileObject(index), getAllFileObjects() — with unclear / missing docs on which is canonical or when to use which. AI agents (and humans reading the docs) end up reverse-engineering the raw data shape instead.

What an agent wrote (consumer-side snippet)

const files =
    filePickerData.files ??
    (filePickerData.fileSrc ? [filePickerData] : [])
for (const f of fil

[Read the thread](https://github.com/tata1mg/catalyst-core/issues/232) · 2026-05-03 · open · 1 comment

### Introduce a runtime-adapter seam (render / static-manifest / transport / logger / config / telemetry)

## Summary

While building a Cloudflare Workers adapter, nearly every shim I wrote patched a place where Catalyst core reaches **directly** for a Node/Express/`fs`/`winston`/`process.env`/`module-alias` primitive or the Node react-dom streaming API. The root cause isn't "missing Workers support" — there's **no seam between framework logic and runtime specifics**.

Proposal: make core runtime-agnostic and delegate environment concerns to a small **Runtime Adapter interface**, with **Node as the d

[Read the thread](https://github.com/tata1mg/catalyst-core/issues/315) · 2026-07-12 · open · 0 comments

### Support TypeScript (.ts / .tsx) extensions for core template entry points

## Motivation

The `catalyst-core` framework (inside files like `expressServer.js`, `handler.js`, `registerAliases.js`, and `validator.js`) hardcodes the `.js` extension when resolving and requiring key entry points (e.g., `server/index.js`, `server/server.js`, `server/document.js`, `src/js/store/index.js`, `src/js/routes/utils.js`, `src/js/containers/App/index.js`, and `client/index.js`). Renaming these files to `.ts`/`.tsx` causes the validator to fail and the build/runtime server to crash wit

[Read the thread](https://github.com/tata1mg/catalyst-core/issues/312) · 2026-07-10 · open · 0 comments

### Enhancing catalyst-mcp: Dynamic AST indexing, active diagnostics, and robust classification

## Motivation

The catalyst-mcp server currently relies on a static knowledge-base.json that is subject to doc-drift/staleness, lacks runtime diagnostics (e.g. detecting port collisions or Babel config conflicts), references transpiled ES5 production code, and uses a strict scope classifier that occasionally blocks valid queries.

## Proposed Behaviour

1. **Dynamic Code Indexing:** Supplement static KB queries with dynamic AST indexing over node_modules/catalyst-core.
2. **Active Diagnostics ('

[Read the thread](https://github.com/tata1mg/catalyst-core/issues/311) · 2026-07-10 · open · 0 comments

## Most recent

### Automatic eager-loading and scoping of catalyst-mcp tools in Catalyst projects

## Motivation

When working in a Catalyst project, the developer and assistant must still manually search schemas and explicitly scope 'catalyst-mcp' for any query, rather than having Catalyst-specific tools pre-registered eagerly by default.

## Proposed Behaviour

All 'catalyst-mcp' tools should be eagerly loaded and registered by default for any Catalyst workspace (e.g. available as direct 'mcp_catalyst_mcp_*' tools). This allows the assistant to call Catalyst checks and operations instantly.

[Read the thread](https://github.com/tata1mg/catalyst-core/issues/310) · 2026-07-10 · open · 0 comments

### Friction in catalyst-mcp configuration: absolute Node path requirements, manual file edits, and tool scoping

## Motivation

Setting up the Catalyst MCP server requires manual global file modification (finding ~/.gemini/antigravity-ide/mcp_config.json vs ~/.gemini/config/mcp_config.json), absolute path node binary resolution (/usr/local/bin/node instead of just node), manual IDE restarts to apply settings, and explicit catalyst-mcp scoping for tool execution.

## Proposed Behaviour

1. **Workspace Auto-Discovery:** Catalyst should support workspace-local MCP server detection (e.g. via .agents/mcp_config

[Read the thread](https://github.com/tata1mg/catalyst-core/issues/309) · 2026-07-10 · open · 0 comments

### Clarification on PUBLIC_STATIC_ASSET_URL for cloud deployments (e.g. Railway)

## Context

PUBLIC_STATIC_ASSET_URL is hardcoded in config.json as 'http://localhost:3005', leading to broken assets in production deployment.

## Expected Guidance

There should be a documented best practice or dynamic fallback for PUBLIC_STATIC_ASSET_URL. For example, if deployed to cloud platforms (like Railway), the build/runtime should automatically default to relative pathing (/assets/) or respect process.env.PUBLIC_STATIC_ASSET_URL dynamically.

## Suggested Labels

`question`, `documenta

[Read the thread](https://github.com/tata1mg/catalyst-core/issues/299) · 2026-07-09 · open · 0 comments

### Missing native .env loader support for environment secrets

## Motivation

Developers must commit secrets to config/config.json or manually parse .env inside preServerInit.

## Proposed Behaviour

Catalyst should support loading .env configurations natively (using dotenv or Node's --env-file) so that local secrets are gitignored out of the box.

## Proposed Fix

Integrate a standard environment variable loader (like dotenv) or support Node.js's native --env-file option in catalyst-core's startup scripts, loading .env variables into process.env before val

[Read the thread](https://github.com/tata1mg/catalyst-core/issues/297) · 2026-07-09 · open · 0 comments

### bug: classifyIntent feedback pattern matches standalone word 'issue' — misroutes debug queries as GitHub issue creation

## Summary

The `feedback` intent regex in `mcp_v2/mcp.js` includes the standalone word `issue` as an alternative match. This causes any query naturally using the word "issue" (e.g. `"I have an issue with routing"`) to be classified as `feedback` intent — triggering the GitHub issue creation workflow instead of the debug flow.

## Current Behaviour

Any query containing the word `"issue"` without strong debug co-signals (error/fail/why) can get classified as `feedback` — causing the LLM to launc

[Read the thread](https://github.com/tata1mg/catalyst-core/issues/275) · 2026-06-18 · open · outside contributor · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/tata1mg/catalyst-core/issues).