Description
A broken workspace custom tool can prevent OpenCode from starting a usable session.
Custom tools are automatically discovered from .opencode/tool/ and .opencode/tools/ and loaded during tool-registry/session initialization. If importing a tool file, or registering one of its exported definitions, throws an error, that error can escape initialization instead of being isolated to the optional extension.
This affects any project containing a broken custom tool; it is not specific to a particular repository or tool file.
Steps to reproduce
-
In any project, create .opencode/tool/broken.ts.
-
Add an import for a package that is not installed:
import "definitely-not-installed"
-
Open the project in OpenCode and start a session.
The same discovery/loading path also applies to custom tools under .opencode/tools/.
Actual behavior
The custom-tool load failure can propagate during tool-registry/session initialization. The session may fail to start normally or fail to become usable, even though the failing code is an optional workspace extension.
Expected behavior
OpenCode should:
- log a useful warning identifying the failing custom-tool file or exported definition and the underlying error;
- skip the entire file when its module cannot be imported;
- skip the failing definition when a module imported successfully but that definition fails during registration or schema conversion, where the failure can be isolated;
- continue loading other valid custom tools; and
- start the session normally.
Failure cases
Failures that should be isolated include, for example:
- missing or unresolved dependencies;
- syntax, compilation, transpilation, or module-format errors;
- exceptions thrown while a module initializes; and
- errors while registering or converting a discovered tool definition.
An import-time failure necessarily skips the entire file because its exports are unavailable. Per-definition recovery applies only after the module imports successfully.
Impact
A single broken optional workspace extension can make core chat unavailable merely by opening the affected project. This makes local experimentation or stale environment-specific custom tools capable of blocking normal use of an otherwise valid workspace.
Suggested resolution
Add error boundaries around each discovered custom-tool import and around registration/conversion of each imported definition. On failure, log enough context to identify the problem, skip the failed file or definition, and continue initializing remaining valid tools and the session.
Additional context
Related: #8006, #10467
Description
A broken workspace custom tool can prevent OpenCode from starting a usable session.
Custom tools are automatically discovered from
.opencode/tool/and.opencode/tools/and loaded during tool-registry/session initialization. If importing a tool file, or registering one of its exported definitions, throws an error, that error can escape initialization instead of being isolated to the optional extension.This affects any project containing a broken custom tool; it is not specific to a particular repository or tool file.
Steps to reproduce
In any project, create
.opencode/tool/broken.ts.Add an import for a package that is not installed:
Open the project in OpenCode and start a session.
The same discovery/loading path also applies to custom tools under
.opencode/tools/.Actual behavior
The custom-tool load failure can propagate during tool-registry/session initialization. The session may fail to start normally or fail to become usable, even though the failing code is an optional workspace extension.
Expected behavior
OpenCode should:
Failure cases
Failures that should be isolated include, for example:
An import-time failure necessarily skips the entire file because its exports are unavailable. Per-definition recovery applies only after the module imports successfully.
Impact
A single broken optional workspace extension can make core chat unavailable merely by opening the affected project. This makes local experimentation or stale environment-specific custom tools capable of blocking normal use of an otherwise valid workspace.
Suggested resolution
Add error boundaries around each discovered custom-tool import and around registration/conversion of each imported definition. On failure, log enough context to identify the problem, skip the failed file or definition, and continue initializing remaining valid tools and the session.
Additional context
Related: #8006, #10467