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

How does our client access OpenCode CLI context in real-time via Bash? (i.e. Logging API) #7573

New Issue
Open
opened 2026-02-16 18:07:37 -05:00 by yindo · 3 comments
yindo commented 2026-02-16 18:07:37 -05:00
Owner
Copy Link
Copy Source

Originally created by @davidbernat on GitHub (Jan 25, 2026).

Originally assigned to: @thdxr on GitHub.

Summary

We are building external tooling and need to understand how to access OpenCode CLI context and conversation content in real-time via bash. We have conducted thorough human + machine review of available options.

Research Conducted

We performed comprehensive analysis across multiple sources:

  • OpenCode website documentation
  • Context7 documentation queries
  • Direct log file structure examination (preferred method)

Directory Structure Found

~/.local/share/opencode/
├── log/                    # `~/.local/share/opencode/log/*.log` - Real-time system events
├── storage/
│   ├── message/            # `~/.local/share/opencode/storage/message/ses_{id}/msg_{id}.json` - Message files
│   ├── session/            # `~/.local/share/opencode/storage/session/{hash}/ses_{id}.json` - Session metadata
│   ├── session_diff/       # `~/.local/share/opencode/storage/session_diff/ses_{id}.json` - Empty arrays
│   ├── part/              # `~/.local/share/opencode/storage/part/msg_{id}/` - Empty directories
│   ├── tool-output/        # `~/.local/share/opencode/storage/tool-output/tool_{id}` - Tool results
│   └── todo/              # `~/.local/share/opencode/storage/todo/` - Task management
└── snapshot/              # `~/.local/share/opencode/snapshot/` - System snapshots

Current Confusion 😕

We notice what appears to be an entirely absent presumptive structure for accessing actual conversation content. The message JSON files contain metadata (IDs, timestamps, token counts) but no actual prompt text or LLM responses.

Are we misconfigured or missing something fundamental?

Basic Access Needs

How do we access via bash:

  • Current context content
  • Context state during compaction events
  • API request/response to LLMs
  • Tool usage details

We also notice that /export requires human intervention for each subagent. How can we automate export processes?

Deployment Concerns

These limitations seem to make it impossible to deploy OpenCode systems to external clients who need programmatic access to conversation content. What options are available for automated context access and archival?

Request: Clarification on proper method for accessing OpenCode conversation content via external bash tools.

Originally created by @davidbernat on GitHub (Jan 25, 2026). Originally assigned to: @thdxr on GitHub. ## Summary We are building external tooling and need to understand how to access OpenCode CLI context and conversation content in real-time via bash. We have conducted thorough human + machine review of available options. ## Research Conducted We performed comprehensive analysis across multiple sources: - OpenCode website documentation - Context7 documentation queries - Direct log file structure examination (preferred method) ## Directory Structure Found ``` ~/.local/share/opencode/ ├── log/ # `~/.local/share/opencode/log/*.log` - Real-time system events ├── storage/ │ ├── message/ # `~/.local/share/opencode/storage/message/ses_{id}/msg_{id}.json` - Message files │ ├── session/ # `~/.local/share/opencode/storage/session/{hash}/ses_{id}.json` - Session metadata │ ├── session_diff/ # `~/.local/share/opencode/storage/session_diff/ses_{id}.json` - Empty arrays │ ├── part/ # `~/.local/share/opencode/storage/part/msg_{id}/` - Empty directories │ ├── tool-output/ # `~/.local/share/opencode/storage/tool-output/tool_{id}` - Tool results │ └── todo/ # `~/.local/share/opencode/storage/todo/` - Task management └── snapshot/ # `~/.local/share/opencode/snapshot/` - System snapshots ``` ## Current Confusion 😕 We notice what appears to be an entirely absent presumptive structure for accessing actual conversation content. The message JSON files contain metadata (IDs, timestamps, token counts) but no actual prompt text or LLM responses. Are we misconfigured or missing something fundamental? ## Basic Access Needs How do we access via bash: - Current context content - Context state during compaction events - API request/response to LLMs - Tool usage details We also notice that `/export` requires human intervention for each subagent. How can we automate export processes? ## Deployment Concerns These limitations seem to make it impossible to deploy OpenCode systems to external clients who need programmatic access to conversation content. What options are available for automated context access and archival? --- **Request**: Clarification on proper method for accessing OpenCode conversation content via external bash tools.
yindo added the docs label 2026-02-16 18:07:37 -05:00
yindo commented 2026-02-16 18:07:38 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 25, 2026):

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

  • #7183: [FEATURE]:Opencode CLI API - Requests API access to opencode for programmatic access
  • #9387: [FEATURE]: opencode session export to markdown or json - Discusses exporting session transcripts programmatically
  • #9292: [FEATURE]: Expose session context to child processes via environment variables - Addresses exposing session metadata to external processes
  • #7535: [FEATURE]: Session logging as OpenAI messages - Covers logging request-response pairs for external processing
  • #4113: Is there any way to debug compaction/token usage/prompts? - Discusses accessing API request/response data and token usage details
  • #10477: Custom tools don't receive project directory in ToolContext - Related to passing context to external tools

These issues address similar concerns about programmatic access to session content, context data, and external integration capabilities. Feel free to ignore if your specific use case requires something different from these existing requests.

@github-actions[bot] commented on GitHub (Jan 25, 2026): This issue might be a duplicate of existing issues. Please check: - #7183: [FEATURE]:Opencode CLI API - Requests API access to opencode for programmatic access - #9387: [FEATURE]: `opencode session export` to markdown or json - Discusses exporting session transcripts programmatically - #9292: [FEATURE]: Expose session context to child processes via environment variables - Addresses exposing session metadata to external processes - #7535: [FEATURE]: Session logging as OpenAI messages - Covers logging request-response pairs for external processing - #4113: Is there any way to debug compaction/token usage/prompts? - Discusses accessing API request/response data and token usage details - #10477: Custom tools don't receive project directory in ToolContext - Related to passing context to external tools These issues address similar concerns about programmatic access to session content, context data, and external integration capabilities. Feel free to ignore if your specific use case requires something different from these existing requests.
yindo commented 2026-02-16 18:07:38 -05:00
Author
Owner
Copy Link
Copy Source

@davidbernat commented on GitHub (Jan 25, 2026):

We have just conducted a human + machine (20/80) study of the related issues, plus a human co-study and peer-review, and found our issue is not addressed in those tickets provided by the bot. We also notice that the overall tone and expectation of those tickets implies that perhaps session message files we require are supposed to be stored in our local directories, but are not. This is not the first time we have explored our local OpenCode logs to find these directories empty. Please advise.

Ticket Summaries in Context of StarlightHQ Needs

#7183 - OpenCode CLI API
This ticket requests generic API access to OpenCode for programmatic interaction, which would directly address StarlightHQ's need for real-time context monitoring and session reconstruction capabilities. While comprehensive, it lacks the specific focus on bash-based access and conversation content that our logging research revealed as missing.

#9387 - Session Export CLI
Requests a TUI command for exporting complete session transcripts to JSON/markdown, which could solve StarlightHQ's archival database requirement but doesn't address the missing actual conversation content we discovered in message files. This approach assumes content exists where our research shows it's absent, making it insufficient for our reconstruction needs.

#9292 - Session Context via Environment Variables
Focuses on exposing session metadata to child processes via environment variables, which would help StarlightHQ correlate external bash watcher output with specific OpenCode sessions. However, this only provides session identification and metadata, not the actual prompts and responses we need for real-time monitoring and complete reconstruction.

#7535 - Session Logging as OpenAI Messages
Proposes logging request-response pairs in OpenAI message format for SFT training data generation, which aligns with StarlightHQ's goal of understanding conversation flow but presumes content exists to be logged. This would help our archival database needs if the fundamental content storage issue were resolved first.

#4113 - Debug Compaction/Token Usage
Addresses debugging context window changes during compaction events, which is directly relevant to StarlightHQ's requirement for clear context change mapping. However, this focuses on debugging existing compaction rather than providing real-time access to conversation content that we need for external monitoring.

#10477 - Custom Tools Project Directory
Discusses custom tools not receiving project directory in ToolContext, which impacts StarlightHQ's ability to build external bash watchers that can properly access project context. This is directly relevant to our real-time monitoring needs but focuses on plugin development rather than the broader logging access problem.

Overall Assessment

While these tickets touch on related needs, none address StarlightHQ's core requirement of accessing actual conversation content via bash because they all presume content exists and is accessible, which our research revealed as a fundamental gap.

@davidbernat commented on GitHub (Jan 25, 2026): We have just conducted a human + machine (20/80) study of the related issues, plus a human co-study and peer-review, and found our issue is not addressed in those tickets provided by the bot. We also notice that the overall tone and expectation of those tickets implies that perhaps session message files we require are supposed to be stored in our local directories, but are not. This is not the first time we have explored our local OpenCode logs to find these directories empty. Please advise. ### Ticket Summaries in Context of StarlightHQ Needs **#7183 - OpenCode CLI API** This ticket requests generic API access to OpenCode for programmatic interaction, which would directly address StarlightHQ's need for real-time context monitoring and session reconstruction capabilities. While comprehensive, it lacks the specific focus on bash-based access and conversation content that our logging research revealed as missing. **#9387 - Session Export CLI** Requests a TUI command for exporting complete session transcripts to JSON/markdown, which could solve StarlightHQ's archival database requirement but doesn't address the missing actual conversation content we discovered in message files. This approach assumes content exists where our research shows it's absent, making it insufficient for our reconstruction needs. **#9292 - Session Context via Environment Variables** Focuses on exposing session metadata to child processes via environment variables, which would help StarlightHQ correlate external bash watcher output with specific OpenCode sessions. However, this only provides session identification and metadata, not the actual prompts and responses we need for real-time monitoring and complete reconstruction. **#7535 - Session Logging as OpenAI Messages** Proposes logging request-response pairs in OpenAI message format for SFT training data generation, which aligns with StarlightHQ's goal of understanding conversation flow but presumes content exists to be logged. This would help our archival database needs if the fundamental content storage issue were resolved first. **#4113 - Debug Compaction/Token Usage** Addresses debugging context window changes during compaction events, which is directly relevant to StarlightHQ's requirement for clear context change mapping. However, this focuses on debugging existing compaction rather than providing real-time access to conversation content that we need for external monitoring. **#10477 - Custom Tools Project Directory** Discusses custom tools not receiving project directory in ToolContext, which impacts StarlightHQ's ability to build external bash watchers that can properly access project context. This is directly relevant to our real-time monitoring needs but focuses on plugin development rather than the broader logging access problem. ### Overall Assessment While these tickets touch on related needs, none address StarlightHQ's core requirement of accessing actual conversation content via bash because they all presume content exists and is accessible, which our research revealed as a fundamental gap.
yindo commented 2026-02-16 18:07:38 -05:00
Author
Owner
Copy Link
Copy Source

@davidbernat commented on GitHub (Feb 12, 2026):

@thdxr It appears that logging is not an issue OpenCode intends to support for enterprise. Can you confirm this for me please?

@davidbernat commented on GitHub (Feb 12, 2026): @thdxr It appears that logging is not an issue OpenCode intends to support for enterprise. Can you confirm this for me please?
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 docs
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#7573
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?