# 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](/mcp/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](https://github.com/lennix1337/Genexus18MCP/issues/87) · 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:

- **Synchronous calls fail fast and clearly.** `genexus_create` returned
  `CreateObjectFailed: "Saving não é permitido neste momento. USER tem um bloqueio CopyModel."`
  immedi

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/79) · 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](https://github.com/lennix1337/Genexus18MCP/issues/67) · 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

- **Genexus18MCP:** 2.36.1
- **GeneXus:** 18 Upgrade 16
- **Build GeneXus:** 18.0.16.189158
- **Sistema operacional:** Windows
- **Ba

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/57) · 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

- **Genexu

[Read the thread](https://github.com/lennix1337/Genexus18MCP/issues/56) · 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.

```json
{
  "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).