anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 10:15:31 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[FEATURE]: Add visibility flags for merged config and system prompt #3238

New Issue
Closed
opened 2026-02-16 17:39:16 -05:00 by yindo · 7 comments
yindo commented 2026-02-16 17:39:16 -05:00
Owner
Copy Link
Copy Source

Originally created by @mlanza on GitHub (Dec 1, 2025).

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

I'm working with instruction files and having difficulty understanding what's actually being loaded and processed. While the documentation mentions the merge strategy for configuration files, there's no way to verify the final merged state that the system is using.

There's some challenge in the black box of sending in inputs and observing outputs, even in a deterministic world. Worse with a non-deterministic model processing inputs. I've spent considerable time (see #2225) trying to understand why certain instructions aren't being acted upon, but without visibility into the system prompt or final configuration, it's difficult to reason about the cause.

I put on my functional programming thinking cap (data flowing through a pipeline taking on different forms) to propose these two additions:

  1. --config flag - Display the final merged configuration object as JSON. This would help verify that all configuration sources (global, project-local, etc.) are being combined correctly. Not correctly you, but correctly me.
  2. --system-prompt flag - Show the fully-merged system prompt being passed to the model for a new session. This way I don't have to interrogate it. I know what it will be told.

Having these debugging tools would make it much easier to set up instruction files reliably and understand why the system behaves the way it does. Currently, the lack of visibility makes it difficult to distinguish between configuration issues and model behavior.

Would this be feasible to add?

Originally created by @mlanza on GitHub (Dec 1, 2025). ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request I'm working with instruction files and having difficulty understanding what's actually being loaded and processed. While the documentation mentions the merge strategy for configuration files, there's no way to verify the final merged state that the system is using. There's some challenge in the black box of sending in inputs and observing outputs, even in a deterministic world. Worse with a non-deterministic model processing inputs. I've spent considerable time (see #2225) trying to understand why certain instructions aren't being acted upon, but without visibility into the system prompt or final configuration, it's difficult to reason about the cause. I put on my functional programming thinking cap (data flowing through a pipeline taking on different forms) to propose these two additions: 1. **`--config` flag** - Display the final merged configuration object as JSON. This would help verify that all configuration sources (global, project-local, etc.) are being combined correctly. Not correctly *you*, but correctly *me*. 2. **`--system-prompt` flag** - Show the fully-merged system prompt being passed to the model for a new session. This way I don't have to interrogate it. I know what it will be told. Having these debugging tools would make it much easier to set up instruction files reliably and understand why the system behaves the way it does. Currently, the lack of visibility makes it difficult to distinguish between configuration issues and model behavior. Would this be feasible to add?
yindo added the discussion label 2026-02-16 17:39:16 -05:00
yindo closed this issue 2026-02-16 17:39:16 -05:00
yindo commented 2026-02-16 17:39:16 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 1, 2025):

This appears to be a feature request about debugging and visibility for OpenCode's configuration and system prompts. Searching the repository for related issues...

@github-actions[bot] commented on GitHub (Dec 1, 2025): This appears to be a feature request about debugging and visibility for OpenCode's configuration and system prompts. Searching the repository for related issues...
yindo commented 2026-02-16 17:39:16 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 1, 2025):

Searching repository for related feature requests and issues...

@github-actions[bot] commented on GitHub (Dec 1, 2025): Searching repository for related feature requests and issues...
yindo commented 2026-02-16 17:39:16 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 1, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #4861: [FEATURE]: on debug mode displaying which system message prompt used - Requests the ability to see which system message prompt is being used in debug mode
  • #3195: Dynamic system prompts for custom agents - Related feature request about dynamically configuring system prompts for agents

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Dec 1, 2025): This issue might be a duplicate of existing issues. Please check: - #4861: [FEATURE]: on debug mode displaying which system message prompt used - Requests the ability to see which system message prompt is being used in debug mode - #3195: Dynamic system prompts for custom agents - Related feature request about dynamically configuring system prompts for agents Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:39:17 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 1, 2025):

Yeah have a config debug command (opencode debug config), rn it just shows your modifications if you have opencode.json files.

I think we should adjust it to fully resolve all the different configs so youy have full visibility into everything

@rekram1-node commented on GitHub (Dec 1, 2025): Yeah have a config debug command (`opencode debug config`), rn it just shows your modifications if you have opencode.json files. I think we should adjust it to fully resolve all the different configs so youy have full visibility into everything
yindo commented 2026-02-16 17:39:17 -05:00
Author
Owner
Copy Link
Copy Source

@mlanza commented on GitHub (Dec 2, 2025):

The --system-prompt flag is really just knowing what you're actually communicating to the model. You have a /thinking toggle in the TUI. Alternately, a /prompting toggle would provide an unfiltered display of what you're actually saying to the model.

@mlanza commented on GitHub (Dec 2, 2025): The `--system-prompt` flag is really just knowing what you're actually communicating to the model. You have a `/thinking` toggle in the TUI. Alternately, a `/prompting` toggle would provide an unfiltered display of what you're actually saying to the model.
yindo commented 2026-02-16 17:39:17 -05:00
Author
Owner
Copy Link
Copy Source

@will-marella commented on GitHub (Dec 5, 2025):

@rekram1-node I've implemented source attribution for debug config - it shows where each value comes from in a _sources object.

The merge process doesn't track sources, so I retraced config loading to avoid touching core code (~200 LOC). But it might be cleaner to add source tracking directly to the merge logic (~80 LOC).

Do you think the sources should be displayed by default or behind a --sources flag?

@will-marella commented on GitHub (Dec 5, 2025): @rekram1-node I've implemented source attribution for debug config - it shows where each value comes from in a _sources object. The merge process doesn't track sources, so I retraced config loading to avoid touching core code (~200 LOC). But it might be cleaner to add source tracking directly to the merge logic (~80 LOC). Do you think the sources should be displayed by default or behind a --sources flag?
yindo commented 2026-02-16 17:39:17 -05:00
Author
Owner
Copy Link
Copy Source

@mlanza commented on GitHub (Jan 14, 2026):

I noticed opencode debug config basically does what I suggested in item 1. This was more important than item 2. Closing.

@mlanza commented on GitHub (Jan 14, 2026): I noticed `opencode debug config` basically does what I suggested in item 1. This was more important than item 2. Closing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3238
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?