Skip to content

[Bug]: OpenCode project-local agents are missing from the agent picker #11871

New issue
New issue
Open
Open
[Bug]: OpenCode project-local agents are missing from the agent picker#11871
Labels
bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

Description

@KostasKgr
KostasKgr
opened on Sep 15, 2026

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Create a project-local OpenCode agent at .opencode/agent/readonly.md inside a project's folder, not global config:

    ---
description: Read-only agent for inspecting the project.
mode: all
permission:
  edit: deny
  bash: deny
  todowrite: deny
---

You are a read-only agent.

  2. From the project directory, run:

    opencode agent list

  3. Confirm that OpenCode reports the project-local agent:

    build (primary)
plan (primary)
readonly (all)

  4. Add or open the same directory as a project in T3 Code.

  5. Select the OpenCode provider and open the agent selector.

Expected behavior

T3 Code should include visible project-local OpenCode agents whose mode is primary or all.

The readonly agent should appear alongside the built-in build and plan agents, matching the agents OpenCode reports when invoked from that project directory.

Actual behavior

The project-local readonly agent is absent from the T3 Code agent selector.

The OpenCode provider cache contains only the globally discovered build and plan agents, even though:

  • The chat session is started with the correct project directory.
  • opencode agent list from that directory reports readonly (all).
  • The agent definition is valid and available in the native OpenCode interface.

This appears to happen because OpenCode agent capabilities are cached at the provider-instance level using a discovery directory that can differ from the selected project's directory. Project-local agents are therefore not represented in the cached model capabilities used by the composer.

Impact

Major degradation or frequent failure

Project-specific agents are a supported OpenCode configuration mechanism. Their absence means workflows and permission profiles defined by individual projects cannot be selected through T3 Code.

Version or commit

  • T3 Code: 0.0.40
  • OpenCode: 1.18.31

Environment

Linux, T3 Code web/server mode, OpenCode provider.

Logs or stack traces

# From the affected project:
$ opencode agent list

build (primary)
compaction (primary)
explore (subagent)
general (subagent)
plan (primary)
summary (primary)
title (primary)
readonly (all)

# Agent options represented in ~/.t3/caches/opencode.json:
[
  "build",
  "plan"
]

The corresponding OpenCode session metadata confirms that T3 starts the chat with the affected project as its working directory.

Related issues

Workaround

Use the project-local agent through the native OpenCode tui or web ui. No T3 Code workaround is currently known.

Activity

  1. juliusmarminge commented on Sep 15, 2026

    @juliusmarminge
    juliusmarminge
    on Sep 15, 2026
    Member

    Triage

    Confirmed bug in OpenCode agent catalog discovery, not the picker UI.

    T3 already filters correctly (!hidden and mode of primary or all). A project-local agent such as .opencode/agent/readonly.md with mode: all would appear if it were in the inventory. It never gets there.

    Why

    OpenCode agent options are baked into the provider-instance model snapshot during checkOpenCodeProviderStatus, using ServerConfig.cwd (the T3 process working directory), then written to ~/.t3/caches/opencode.json. That cache is one file per instance and does not include workspace snapshots.

    Per-project refresh exists only for skills:

    • OpenCodeDriver.snapshotForCwd reloads app.skills with the project directory
    • ServerProviderWorkspaceSnapshot stores skills / slashCommands only
    • composers resolve skills per cwd, but read the agent selector from instance-level models[].capabilities

    Chat sessions already start with the correct project directory (adapter path). Catalog discovery does not follow that directory. That matches the report: opencode agent list shows readonly (all), while the cache only has build and plan.

    This is the same class of cwd bug skills already fixed, left unfixed for agents after #8480 switched discovery to app.agents.

    Not a duplicate

    Suggested fix

    Reload agents in snapshotForCwd via app.agents with the project directory, persist cwd-scoped agent options (workspace snapshot / contracts), and have web + mobile composers resolve the agent picker from that cwd the same way they resolve skills. Changing only the initial probe cwd is not enough: T3 is multi-project and the instance cache would still be a single list.

    Surfaces

    Server snapshot + cache first. Agent pickers on web, desktop (wraps web), and mobile all consume that catalog.

  2. juliusmarminge
    added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Sep 15, 2026

  3. daniel0x00 commented on Oct 12, 2026

    @daniel0x00
    daniel0x00
    on Oct 12, 2026

    This issue/bug is quite critical for us. We have invested a lot of time in opencode harnessing with a primary agent and many subagents; but the main agent is not possible to be picked and saved as default in T3.

  4. juliusmarminge commented on Oct 22, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 22, 2026 – with GitCafe Production
    Member

    Existing fix: #21532 covers workspace-local OpenCode agent discovery and explicitly fixes this issue. It is open and awaiting human approval for agent-default/execution behavior. No duplicate fix PR is needed; leaving this issue open until that work lands. On main b5a226e49c, OpenCode 1.18.18 lists the reported readonly (all) fixture from its project directory; the T3 picker comparison was not completed before locating the existing fix.

  5. juliusmarminge commented on Oct 22, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 22, 2026 – with GitCafe Production
    Member

    Reproduced on current main 3b95e7831b, Linux web/server mode with OpenCode 1.18.18. Created the reported .opencode/agent/readonly.md, ran opencode agent list from that project, added the same folder in T3, selected OpenCode / Big Pickle, and opened the agent menu. Native OpenCode lists readonly (all); T3 offers Build and omits readonly. The isolated server cache contains only build/plan agent options.

    Runtime discovery transcript

    Current main: project-local readonly agent missing from the Agent menu

    Existing fix #21532 remains open; added bugfix while preserving its other labels. It has 31 successful checks, reports conflicts against current main, and its existing report requires human review of agent-default/execution behavior. No duplicate fix PR or branch changes. Leaving this issue open for that fix.

  6. the-data-sherpa commented on Oct 28, 2026

    @the-data-sherpa
    the-data-sherpa
    on Oct 28, 2026

    Adding evidence that on OpenCode 2 this bug is broader than project-local agents. With OpenCode 2.2.0, no agents reach the picker at all, including globally defined primary agents. The agent dropdown cannot offer anything beyond the default.

    Environment

    • T3 Code (Beta) 0.1.3, macOS desktop
    • OpenCode 2.2.0 (provider cache reports status: ready, "OpenCode 2.2.0 lists 88 models")

    Setup

    A global (not project-local) primary agent at ~/.config/opencode/agents/lead.md:

    ---
description: Coordinate scoped work across coder, verifier, and specialized reviewers; ...
mode: primary
...
---

    OpenCode's own API reports it. The agent qualifies on every filter T3 applies (mode: primary, hidden: false):

    $ opencode api agent.list
lead        mode=primary   hidden=False
build       mode=primary   hidden=False
plan        mode=primary   hidden=False
general     mode=subagent  hidden=False
... (25+ subagents)

    Actual

    ~/.t3/caches/opencode.json (refreshed today) contains zero agent option descriptors on every model. The custom agent is missing, and so are build and plan:

    lead in cache: False
No agent optionDescriptor found on any model

    The T3 agent dropdown therefore has no agents to offer, and the globally defined lead agent is unselectable. This differs from the original 1.x report, where the global built-ins (build, plan) were discovered and only project-local agents were missing.

    Likely cause

    OpenCode 2 replaced the v1 REST paths with an operation-ID API surface. GET /agent on a 2.2.0 server now returns the web app's HTML shell rather than JSON. The working call is the agent.list operation (opencode api agent.list). If catalog discovery still requests the v1 path, it silently receives HTML and bakes an empty agent catalog into the provider cache. That matches what the cache shows.

    Implication for the fix

    #21532 scopes agent discovery to the workspace, which addresses the 1.x project-local symptom. If discovery itself gets nothing back from an OpenCode 2 server, workspace scoping alone will not restore the picker. Worth verifying that PR against OpenCode 2.x before this issue is closed on it.

  7. soares-daniel commented on Oct 29, 2026

    @soares-daniel
    soares-daniel
    on Oct 29, 2026

    Cross-linking the OpenCode 2 half, since it is now reproduced independently.

    On T3 Code main 5211acfe95, Linux web/server, OpenCode 2.2.0, with no project-local agents:

    • Every model in the provider cache has zero agent option descriptors. The picker only has its fixed Build default (Plan appears in plan mode).
    • The cause is separate from the 1.x cwd/discovery problem in this issue: the v2 snapshot path emits only the reasoning option, and the v2 adapter hard-codes build/plan instead of using a selected agent.

    I verified a narrow v2 fix (agent.list plus the configured default_agent feeding the agent descriptor, then agentFor reading the selection) with focused tests and vp run check:changed (47 tests). Details and the patch are on #21532: #21532 (comment)

    This does not close the original project-local case here; #21532 remains the fix for that. I am not opening a duplicate PR.

  8. violabg commented on Oct 31, 2026

    @violabg
    violabg
    on Oct 31, 2026

    Another reproduction of the OpenCode 2 half, this time with project-local agents.

    Version: T3 Code (Nightly) desktop 0.1.6-nightly.20261031.3977, local server, macOS arm64
    OpenCode: 2.2.5

    Repro

    1. Define custom mode: primary agents in a project's .opencode/agents/.
    2. Run opencode debug agents from that project. The custom agents are listed with hidden: false.
    3. Open that project in T3 Code and select an OpenCode model.
    4. There is no way to select a custom agent.

    Evidence

    • All 38 OpenCode models in ~/.t3/caches/opencode.json have only a variant option descriptor, and none has agent.
    • At this tag, openCode2ModelCapabilities (packages/provider-opencode/src/server/status.ts:582) only builds variant, and agentFor (packages/provider-opencode/src/server/v2/adapter.ts:614) only returns plan or build.
    • The three commits on main after this tag don't touch this.

    Regression status: the reporter remembers selecting a custom agent on OpenCode 2 a few releases ago, but this isn't confirmed. The v2 capabilities code had no agent descriptor at de34391427 (Oct 2), agentFor was already hard-coded at e62161bc5b (Oct 9), and the local database has no agent selection recorded since Sep 13.

    Partial workaround: a project .opencode/agents/build.md replaces the Build agent in opencode debug agents. This wasn't verified in a T3 Code turn.

    Produced with t3 triage by Claude Code (Claude Opus 5.5).

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions