Activity

1. youngjoel

   added

   needs-triage

   bug

   on Oct 19, 2026
2. mnriem

   added

   bug-assess

   and removed

   needs-triage

   bug

   on Oct 19, 2026
3. github-actions commented on Oct 19, 2026

   

   github-actionsBot

   on Oct 19, 2026 – with GitHub Actions

   Contributor

   More actions

   Bug assessment — opencode-hidden-glob: Likely valid, needs reproduction · severity medium

   ---

   Bug Assessment: .specify ignored with other dot-files by opencode glob

   • Slug: opencode-hidden-glob
   • Created: 2026-10-19T18:39:17.977+00:00
   • Source: issue [Bug]: .specify ignored with other dot-files by opencode glob #5028
   • Verdict: likely valid, needs reproduction
   • Severity: medium

   Report (summarized)

   The reporter uses Specify CLI 0.11.3 with opencode on Debian GNU/Linux 13.7 and Python 3.14.2, using local/open-weight models such as k2-horizon or nemotron-ultra. During speckit.specify passes, opencode's default glob reports Pattern: .specify/**/* and No files found. The reporter says adding a project-root .ignore containing !.specify/ and !.specify/** makes the directory observable, and asks whether the hidden .specify layout should change.

   Symptom

   When opencode's default file glob excludes dot-directories, local models cannot discover the Spec Kit files under .specify, including the constitution, templates, scripts, and other runtime context needed by the commands. The expected behavior is that the core files needed by Spec Kit commands are discoverable in the supported opencode integration without a manual glob/ignore workaround.

   Reproduction

   1. Initialize a project with Specify CLI 0.11.3 and the opencode integration.
   2. Run several speckit.specify passes using an open-weight/local model such as k2-horizon or nemotron-ultra.
   3. Observe opencode issuing a glob for .specify/**/* and returning no files.
   4. [NEEDS CLARIFICATION: Confirm whether the same failure occurs with the current Spec Kit release and the exact opencode version/configuration.]
   5. Add a project-root .ignore with !.specify/ and !.specify/**, then repeat the operation and verify whether discovery succeeds. This workaround is reported by the issue author but is not independently reproduced here.

   Suspected Code Paths

   • src/specify_cli/integrations/opencode/__init__.py:OpencodeIntegration.config — declares opencode's integration root as the hidden .opencode/ directory and its command directory; it contains no mechanism to configure opencode's project file-discovery behavior.
   • src/specify_cli/shared_infra.py:SPECIFY_GITIGNORE_CONTENT — intentionally manages only .specify/.gitignore for machine-local state and documents the .specify/ tree as shareable. This does not create a project-root .ignore or otherwise opt hidden paths into opencode globbing.
   • src/specify_cli/shared_infra.py shared-infrastructure installation logic (around the managed .specify/.gitignore block) — creates and refreshes the hidden .specify tree, including its templates/scripts and manifests.
   • templates/commands/*.md (for example templates/commands/plan.md and templates/commands/constitution.md) — instruct the agent to read project artifacts such as /memory/constitution.md and invoke scripts whose resolved paths live below .specify; these commands therefore depend on discovery/access to the hidden tree when the agent chooses to glob for it.
   • tests/integrations/test_integration_opencode.py:test_setup_writes_to_canonical_dir and the shared integration inventory tests — verify opencode command placement and .specify file creation, but do not cover hidden-directory discovery by an opencode model.

   Root Cause Hypothesis

   Confidence: medium. The report is consistent with the repository's design: Spec Kit deliberately stores shared runtime files in a hidden .specify directory, while the reported opencode glob behavior excludes dot-directories unless an ignore rule explicitly re-includes them. The opencode integration config controls command registration and CLI invocation, not opencode's glob implementation, so the immediate failure is a compatibility gap between the hidden Spec Kit layout and opencode's default discovery policy. Reproduction is still needed to confirm the exact opencode version, whether its default glob semantics are responsible, and whether the failure is limited to open-weight models or affects all models.

   Proposed Remediation

   Preferred: Add an opencode-specific compatibility path that makes the required project context discoverable without changing the canonical .specify layout. The least disruptive candidate is to generate or document the supported project-root .ignore opt-in for .specify/ when the opencode integration is initialized, while preserving an existing user-authored .ignore and clearly recording the managed entry. If opencode has a supported configuration setting for including hidden files, prefer writing that setting instead of relying on a repository-root ignore file.

   The implementation should be scoped to opencode rather than changing all integrations: the hidden .specify convention is used throughout the CLI and moving it to specify/ would be a broad compatibility/API change affecting scripts, manifests, tests, documentation, and existing projects. A migration to a non-hidden directory could be considered only as a separately versioned long-term design change.

   Alternatives:

   • Add explicit discovery guidance to the opencode integration documentation/command prompts, telling users or the model to read known .specify paths directly. This avoids modifying project ignore files but may not help if opencode blocks hidden-path globbing at the tool layer.
   • Change the global layout from .specify/ to specify/. This would improve default discoverability but has high migration and backward-compatibility cost and is not appropriate as a narrowly scoped bug fix.

   Files likely to change:

   • src/specify_cli/integrations/opencode/__init__.py or the shared integration setup/lifecycle code, if opencode-specific discovery configuration is supported.
   • src/specify_cli/shared_infra.py or the opencode setup path, if a managed root .ignore entry is selected.
   • docs/reference/integrations.md and opencode integration guidance, for the supported behavior and migration/workaround details.
   • tests/integrations/test_integration_opencode.py and relevant shared-infrastructure tests.

   Tests to add or update:

   • Initialize opencode in a temporary project and assert the selected discovery configuration/ignore entry is created and includes .specify/.
   • Verify an existing user-authored .ignore is preserved and that repeated init/upgrade does not duplicate or overwrite unrelated rules.
   • Verify non-opencode integrations do not receive the opencode-specific configuration.
   • Add a regression/characterization test for the generated project layout and the exact .specify paths required by core commands.
   • If the fix depends on opencode behavior, run an integration test against the supported opencode version or document the external-version constraint.

   Risks & Considerations

   • Modifying a root .ignore may be surprising and must preserve user content, ownership, and formatting; the implementation needs an explicit managed-entry strategy.
   • A project-root .ignore may affect tools other than opencode, so the scope and rationale should be documented.
   • Moving .specify would break existing scripts, manifests, extensions, presets, command text, and projects unless a careful migration/compatibility layer is provided.
   • The report omits the opencode version and does not include a failing command transcript beyond the glob result, so the exact external behavior remains unverified.

   Open Questions

   • [NEEDS CLARIFICATION: What exact opencode version and configuration were used?]
   • [NEEDS CLARIFICATION: Does opencode provide a project configuration option to include hidden files, and is that preferable to a root .ignore entry?]
   • [NEEDS CLARIFICATION: Do cloud models succeed because they use a different discovery strategy, or is the issue model/provider-independent?]
   • [NEEDS CLARIFICATION: Does adding the two .ignore negation rules reliably fix all required .specify reads, including direct script execution and extension/preset files?]

   Generated by 🐛 Assess Bug from Labeled Issue for #5028 · copilot · gpt52codex · 2.13 AIC · ⌖ 0.66 AIC · ⊞ 22.3K · ◷
4. github-actions

   added

   needs-reproduction

   severity-medium

   on Oct 19, 2026
5. mnriem commented on Oct 19, 2026

   

   mnriem

   on Oct 19, 2026

   Collaborator

   More actions

   This seems best addressed within the OpenCode integration rather than by renaming .specify, which would have compatibility implications across Spec Kit.

   One possibility would be an opt-in integration option, for example—not existing functionality:

   specify integration install opencode \
     --integration-options="--configure-ignore-file"

   This could create or update the project’s .ignore with appropriate Spec Kit exceptions, preserving existing user rules. We would first need to verify that those exceptions resolve the issue in the affected OpenCode version: explicit hidden-path exclusions in the glob tool may require a separate OpenCode-side fix.
6. youngjoel commented on Oct 19, 2026

   

   youngjoel

   on Oct 19, 2026

   Author

   More actions

   " the exact opencode version, "
   1.18.31

   I have not seen problems with the cloud models. According to google search AI:

   If you are using them via official API Keys or OAuth, the latest versions of Claude and Gemini profiles in OpenCode have hardcoded client fallbacks. When Gemini or Claude explicitly try to look for project instructions and get No files found back from a standard glob tool call, their foundational agent prompts tell them to double-check using a direct file read (read_file(".specify/spec-template.md")) or standard shell listings.
   Because OpenCode's read_file tool targets an explicit path rather than scanning a directory pattern, it bypasses the ripgrep hidden-file exclusion entirely.

   Regarding the --integration-options, would it be better to have the .ignore change/addition be opt-out instead of opt-in?
7. youngjoel commented on Oct 19, 2026

   

   youngjoel

   on Oct 19, 2026

   Author

   More actions

   I am hearing rumors that the glob problem has been fixed in opencode v2 vs the still active opencode v1 lineage. Stand by I guess :-(
8. mvanhorn commented on Oct 20, 2026

   

   mvanhorn

   on Oct 20, 2026

   Contributor

   More actions

   OpenCode 1.18.31 and 1.19.3 run that glob through ripgrep without --hidden, so dot-directories are skipped.

   OpenCode install and upgrade accept an opt-in --configure-ignore-file flag that appends whichever of !.specify/ and !.specify/** is not already an exact line, keeps existing .ignore bytes as a prefix (including non-ASCII text, CRLF, and a missing final newline), and records the root file as partial ownership.

   #5032