Missing /details command in opencode v1

[oliver-14203]

Description

Since upgrading to the OpenTUI version of opencode (v1), the /details command is missing. The command allowed users to hide the details of tool calls, allowing for a more minimal UI.

This is particularly useful in projects in which processes are more automated, and significant supervision of the tool calls isn't required, cleaning up the UI.

OpenCode version

1.0.15

Steps to reproduce

1. Type /details
2. It isn't there

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

[github-actions[bot]]

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

• #3065: Bug: Tool Calls are not shown directly if tool details are toggled off - Similar functionality around controlling tool call visibility
• #3641: OpenTUI: /thinking command is missing - Another missing slash command in OpenTUI v1
• #3748: Export functionality seems to be missing in opentui version - Missing functionality in OpenTUI version
• #3642: 1.0.2 Missing ability to open editor for history - Missing functionality after v1 upgrade

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

[thdxr]

so i didn't add this yet because the default view is already very compressed - you find that it's still too noisy? we only show edit and bash tool calls

[rekram1-node]

Another user wants /details or some equivalent to be able to see more detail from tool calls

[scottrbaxter]

Adding to this, i had a bindkey set to details which was really useful to quickly toggle on/off and re-reference tool calls. definitely would like to see this re-implemented. currently holding out with 0.15.31 until more features like this are added back in.

thanks for rapid turnaround and all of the community responses!

[luifr10]

Hello, I agree that this feature seems essential to me. Once a call to a tool has been made, it is useful to be able to see the raw output to that call.

[falconepl]

I'm not sure if that falls under what /details command could be used for, but it would be super useful to be able to control verbosity level in some way. To give you an example, here's one prompt against some send.rs Rust file (a simple question, with a typo, rather than a request to apply any change):

Can we change "String value from thread" to "Moved value from thead" in @examples/send.rs. Would it be correct? txt examples/send.rs

And here's the model response (Grok Code Fast 1 in this case):

The user wants to change "String value from thread" to "Moved value from thead" in examples/send.rs. They ask if it would be correct.

Reviewing code change

• The user wants to modify a string in examples/send.rs, changing "String value from thread" to "Moved value from thead."
• Checking line 15, the original string is part of a println! macro, likely related to thread handling.

Assessing correctness

• The change replaces "String" with "Moved" and has a typo ("thead" instead of "thread").
• Need to verify if "Moved value from thread" accurately reflects the code's behavior, especially thread ownership semantics.

Reviewing code change

• The string "String value from thread" is printed inside a thread, using a closure with move ||, indicating the string s is moved into the thread.

Yes, it's correct (fixing "thead" to "thread"). The value is moved to the thread and printed from it.

Build grok-code

As you can see, that's quite a lot of text for a simple yes/no question. Meanwhile, if it was possible to set a minimal verbosity in some way (in OpenCode session or settings), we could expect the output to be just:

Yes, it's correct (fixing "thead" to "thread"). The value is moved to the thread and printed from it.

Being able to make OpenCode output concise with some simple setting/option could be very useful in some usage scenarios