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

Reported issues for genexus

Pod holds 19 of 31 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 genexus.

Most discussed

SdkSurfaceProbe only sees already-loaded assemblies, so the endpoint backlog under-reports the SDK surface

What I ran into

SdkSurfaceProbe.Run() enumerates AppDomain.CurrentDomain.GetAssemblies() (src/GxMcp.Worker/Services/SdkSurfaceProbe.cs:78). That means it can only describe assemblies the worker has already loaded. An assembly that is never referenced by GxMcp.Worker.csproj, and never pulled in transitively, is structurally invisible to it.

This isn't a bug in the probe — it follows from starting at the AppDomain. But it does mean the backlog derived from it (`docs/sdk_uncovered_

Read the thread · 2026-08-12 · closed · outside contributor · 3 comments

[Feature] Detect and report when the IDE holds the model, instead of async jobs hanging as 'running'

Opening an issue first, as CONTRIBUTING.md asks for behavior changes.

Problem

When the GeneXus IDE has the KB open and shows a modal (e.g. "X has been modified by USER. Do you want to reload it?"), the SDK is blocked until a human clicks it. Today the MCP has two different behaviors for that same condition:

Read the thread · 2026-08-10 · closed · outside contributor · 2 comments

[Bug] PatternInstance dryRun returns ok without exercising the save path; identical payload then fails WriteNotPersisted after 159s

Summary

genexus_edit … part=PatternInstance dryRun=true returns ok / WriteDryRun after parsing the input XML, without exercising any part of the save path. The same payload, submitted 9 seconds later without dryRun, spent 159 seconds and failed with WriteNotPersisted.

Since the project already knows that semantic PatternInstance saves are an open wall (docs/wwp_pattern_investigation.md — "o validador custom de WWP rejeita sem diagnóstico útil"), the dry run is currently

Read the thread · 2026-08-02 · closed · outside contributor · 2 comments

[Bug] Nullable = Yes retorna sucesso, mas não é persistido na estrutura da Transaction

Resumo

Não foi possível alterar uma ocorrência de atributo de Transaction para Nullable = Yes pelo MCP.

Algumas chamadas retornam PropertyApplied ou StructureUpdated, mas a releitura da estrutura continua mostrando nullable: No e o DDL continua gerando NOT NULL.

A mesma alteração funciona normalmente quando realizada pela IDE GeneXus.

Ambiente

Read the thread · 2026-07-31 · closed · outside contributor · 2 comments

[Bug] Variáveis baseadas em Domain são criadas com metadados inválidos e falham na especificação

Resumo

Ao adicionar variáveis a uma Procedure usando um Domain como tipo, o MCP informa que as variáveis foram criadas e a leitura textual aparenta estar correta. Porém, a especificação falha porque os metadados internos da variável ficam inválidos ou incompletos.

Nos diagnósticos do especificador, a definição aparece com o tipo interno 249 e uma referência vazia representada por []. Isso sugere que o BasedOnReference do Domain não foi persistido corretamente.

Ambiente

Read the thread · 2026-07-31 · closed · outside contributor · 2 comments

[Bug] Variables editor persists Properties type as NUMERIC(4) in a new Procedure

What happened

When creating the Variables part of a new Procedure through genexus_edit, variables declared with the GeneXus Properties type were persisted as NUMERIC(4).

A subsequent attempt to correct the type using genexus_variable with action: "modify" reported DomainReference, but the persisted variables remained NUMERIC(4).

The worker did not crash or disconnect.

The exact tool call

Names were replaced with generic placeholders.

{
  "tool": "genexus_edit"

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/46) · 2026-07-23 · closed · outside contributor · 2 comments

### build de SDTs e Variáveis tipo WebSession

# Limitação do GeneXus MCP: tipagem de SDT Collection e WebSession

**Contexto:** KB GeneXus 18 (`SGE_APIs_v2`), uso via GeneXus MCP (worker + ferramentas `genexus_create` / `genexus_edit` / `genexus_variable` / `genexus_properties` / `genexus_io` / `genexus_create` `save_as`).  
**Impacto:** frentes de migração API REST que dependem de SDTs com coleções tipadas e de Procedures/APIs que gravam/lêem `WebSession` ficam bloqueadas ou exigem workarounds IDE / import XPZ fora do fluxo MCP-only.  
**S

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/33) · 2026-07-16 · closed · external user · 4 comments

### [Bug] MCP fails to read SDPanel (Smart Device Panel) source — reports empty content incorrectly

## [Bug] MCP fails to read SDPanel (Smart Device Panel) source — reports empty content incorrectly

### Description
When using the GeneXus MCP server to read a **Smart Device Panel (SDPanel)** object, the `genexus_read` tool correctly identifies the object type as `SDPanel`, but returns all parts (Source, SDLayout, SDVariables, SDConditions, Documentation) as **empty**, even though the object is actually used in the KB and has real, non-trivial content.

The dependency analysis (`genexus_analyze

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/29) · 2026-07-10 · closed · external user · 2 comments

## Most recent

### genexus-mcp 2.45.1 Corrupta Instalacion

Al momento de ejecutar la instalación npx genexus-mcp --init , da un error que no encuentra la carpeta scripts el fichero validate.js y no deja instalar totalmente el programa

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/114) · 2026-08-23 · closed · external user · 1 comment

### [Bug]   Worker killed by IdleTimeout during an active Build (recurring, multi-day)

```markdown
## What happened

The MCP worker gets killed by its own IdleTimeout watchdog while a `Build` operation is still actively
running, not just when genuinely idle. From the client side, this surfaces ~30 minutes later as a
transport-level timeout ("sent no response or progress for 1800s"), with no earlier signal that the
worker had already died mid-build.

This is not a one-off: the crash ledger shows it recurring across multiple days with `lastOp: "Build"`:

- 2026-08-17T14:57:47Z — pid

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/113) · 2026-08-21 · closed · external user · 1 comment

### [Bug] Worker binary missing after fresh npx install

## What happened

Fresh npx cache install of genexus-mcp had an empty `publish/worker/` folder (no `GxMcp.Worker.exe`).
Every KB tool call failed with "Worker NOT FOUND at ...\publish\worker\GxMcp.Worker.exe", even though
`config.json`'s `GeneXus.WorkerExecutable` pointed at a different, valid path.

## The exact tool call

```json
{ "tool": "genexus_kb", "args": { "action": "open", "path": "<KB_PATH>", "alias": "<KB>" } }

Expected vs actual

- Expected: Worker spawns from either the default pu

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/112) · 2026-08-21 · closed · external user · 1 comment

### [Bug] genexus_structure: SDT fields cannot be persisted as Attribute:<Name> (basedOnAttribute)

## Summary
When updating SDT structure via MCP, fields that should be bound to canonical KB attributes (`Attribute:<AttributeName>`) are **not persisted**. Tools return success (`StructureUpdated`) but re-read APIs and the GeneXus IDE designer show unchanged primitive/domain types.
This breaks parity with the GeneXus IDE, where SDT members can be explicitly typed as `Attribute:<Name>` (e.g. `SDTCardapiosUpsertRequest.CardapioAceitaTroca` → `Attribute:CardapioAceitaTroca`).
## Expected behavior
-

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/109) · 2026-08-19 · closed · external user · 1 comment

### TryPreloadSdkAssemblies returns silently when the GeneXus path does not resolve, so genexus_sdk_probe can report a pre-#87 partial surface as complete

Follow-up to #87 (fixed in v2.41.0 by `TryPreloadSdkAssemblies`).

## Problem

`TryPreloadSdkAssemblies` bails out silently when the GeneXus installation path does not resolve:

https://github.com/lennix1337/Genexus18MCP/blob/56c05b4b688dede49e1b7d57e8057832a11cd8bd/src/GxMcp.Worker/Services/SdkSurfaceProbe.cs#L376-L380

```csharp
string gxPath = Environment.GetEnvironmentVariable("GX_PROGRAM_DIR")
    ?? Environment.GetEnvironmentVariable("GX_PATH")
    ?? @"C:\Program Files (x86)\GeneXus\GeneX

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/94) · 2026-08-13 · closed · outside contributor · 1 comment

### [Bug] genexus_edit PatternInstance: userAction gxobject attribute is silently dropped on persist (rejectedByPersist)

## What happened

Writing a `<userAction>` into a WorkWithPlus `PatternInstance` via `genexus_edit` persists
every attribute **except `gxobject`**, which is dropped by the SDK save path. The tool returns
`PatternVerificationMismatch` and reports `rejectedByPersist=[gxobject]`.

The resulting button renders in the UI and keeps its `condition`, but calls nothing.

Reproduced **3/3**, across three variations:

1. `gxobject="MyModule.MyAiProcedure"` (module-qualified name) - rejected
2. `gxobject="{

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/82) · 2026-08-12 · closed · outside contributor · 1 comment

### [Bug] ClassifyErrorCategory knows only 2 of GeneXus's 12 diagnostic code families — gtm#### build-infra errors are reported as code errors

## Summary

`BuildService.ClassifyErrorCategory` splits build diagnostics into `environment` / `spec` / `code`, but it only recognises **2 of the 12 diagnostic code families GeneXus actually emits**. Everything else silently falls through to `code`.

The consequence that bites: **`gtm####` errors (GeneXus Tasks MSBuild — build infrastructure) are reported as `code` errors.** That suppresses `envErrorsHint` and sends the agent hunting for a bug in the edited object when the actual problem is the 

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/81) · 2026-08-11 · closed · outside contributor · 1 comment

### [Bug] rebuild ignores `target` and runs RebuildAll when given a CSV list (regression of #53, fixed in v2.36.0)

## What happened

`genexus_lifecycle` with `action: "rebuild"` and a **CSV list of 4 targets** ignored the targets and
ran a **KB-wide RebuildAll**. The response itself reports `"Action": "RebuildAll"`, and the log shows
the specifier walking objects that have nothing to do with the requested targets.

This is the same symptom as #53, which was closed as fixed in
[v2.36.0](https://github.com/lennix1337/Genexus18MCP/releases/tag/v2.36.0):

> `genexus_lifecycle action=rebuild` now honors target pa

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/80) · 2026-08-11 · closed · outside contributor · 1 comment

### [Bug] async genexus_edit reports job status=failed for a write that did persist (PatternInstance)

## What happened

A `genexus_edit part=PatternInstance` run with `async: true` finished as `status: "failed"`, `saved: false`, `WriteNotPersisted`.

**The write had actually persisted.** The pattern generated the new WebComponent from it, and a tag-by-tag diff against the pre-edit snapshot shows every expected element added and **zero controls lost**.

Any automation that polls `status` treats this as a failure and retries — which would duplicate the edit.

## The exact tool call

```json
{
  "t

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/71) · 2026-08-06 · closed · outside contributor · 1 comment

### [Bug] object_atomic rolls back a valid object because the SDK normalizes the Source it just wrote

## What happened

`genexus_create action=object_atomic` creates the object, writes variables / rules / source, then verifies the persisted Source against the requested one. The SDK **re-indents** what it receives, so for any Source with leading whitespace the two never match. The step is reported as failed and **the whole object is rolled back and deleted** — work is lost, not just time.

## The exact tool call

```json
{
  "tool": "genexus_create",
  "args": {
    "action": "object_atomic",
   

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/70) · 2026-08-06 · closed · outside contributor · 1 comment

### [Bug] AGENTS.md tells agents folder/module placement is impossible - it shipped in v2.35.0

## Summary

`AGENTS.md` still documents folder/module placement as a hard SDK wall. That section was correct until **v2.35.0 (2026-07-24)**, which implemented it — but the doc wasn't updated in the same commit.

Because `AGENTS.md` is loaded as context in **every** agent session (Claude Code imports it via `CLAUDE.md`, and it's the cross-tool convention file for Cursor / Codex / Aider), the practical effect is that coding agents read an authoritative "this is not supported" and **never call `gen

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/65) · 2026-08-02 · closed · outside contributor · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/lennix1337/Genexus18MCP/issues).