Thanks to visit codestin.com
Credit goes to github.com

Skip to content

fix(cli): keep instance context during config validation - #14084

Open
Kush2806 wants to merge 1 commit into
Kilo-Org:mainfrom
Kush2806:fix/config-validation-instance-context
Open

fix(cli): keep instance context during config validation#14084
Kush2806 wants to merge 1 commit into
Kilo-Org:mainfrom
Kush2806:fix/config-validation-instance-context

Conversation

@Kush2806

@Kush2806 Kush2806 commented Sep 13, 2026

Copy link
Copy Markdown

Fixes #14040

What

Editing any .kilo/command, .kilo/agent, or .kilo/mode markdown file through the agent appended a bogus validation error to the tool result:

ERROR: .../.kilo/command/foo.md
  Failed to parse frontmatter: No context found for instance

It was content-independent (fired even without frontmatter) and only for project markdown.

Root cause

ConfigValidation.check is a plain async helper invoked from the file tools via Effect.promise(() => ConfigValidation.check(filepath)). Tools resolve the project instance from the Effect fiber (InstanceState.context -> InstanceRef), not from async-local storage. capture() can only read the fiber reference synchronously, so the first await inside check (await existing()) dropped it. markdown() then called Instance.current unguarded, which threw LocalContext.NotFound("instance"), and the surrounding catch mislabelled it as a frontmatter parse error.

Change

Capture the instance synchronously at the top of check() and thread it through isConfig and markdown. Project markdown is skipped when there is genuinely no instance (it cannot be scoped); global/trusted config still validates. The untrusted-markdown fileScope used for source-read confinement is computed identically, so the #12168 guard is unchanged.

Testing evidence

  • New regression test in test/kilocode/config-validation.test.ts drives the fiber-only context (the production tool path) and asserts the file validates. It reproduced the exact reported string before the fix and passes after.
  • bun test ./test/kilocode/config-validation.test.ts -> 11 pass
  • bun test ./test/tool/write.test.ts ./test/tool/edit.test.ts ./test/tool/apply_patch.test.ts -> 71 pass
  • bun test ./test/config/markdown.test.ts ./test/kilocode/config-validation.test.ts -> 48 pass
  • Security: test/config/config.test.ts exfiltration case passes; test/kilocode/config/variable.test.ts + config/markdown.test.ts -> 15 pass
  • bun run typecheck (packages/opencode), bun run lint (0 errors), prettier, and the annotations checker are clean

Changeset included (patch).

Notes

Reproduced on macOS as well as the reported Windows environment, so this is not platform-specific.

Config validation runs from file tools as a plain async helper awaited from an Effect fiber. The ambient instance context is only readable synchronously, so the awaits inside check() dropped it and moved on; markdown() then threw "No context found for instance", which was misreported as a frontmatter parse error on every .kilo/command and .kilo/agent markdown edit.

Capture the instance once at entry and thread it through. Fixes Kilo-Org#14040.
@Kush2806

Copy link
Copy Markdown
Author

Hi — small heads-up: the Kilo Code Review check failed after 34s with "GitHub credential service is unavailable", right around the GitHub API 500/502s earlier, so it never actually ran against the diff (0 annotations). The Actions workflows are queued as action_required.

Could a maintainer approve the workflow runs and re-run the review? Happy to address anything it flags once it executes. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Config validator: "Failed to parse frontmatter: No context found for instance" on every .kilo/command/*.md file, even with no frontmatter

1 participant