Repository navigation
How does our client access OpenCode CLI context in real-time via Bash? (i.e. Logging API) #10592
Description
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.
Activity
github-actions commentedon Jan 26, 2026
This issue might be a duplicate of existing issues. Please check:
opencode session exportto markdown or json #9387: [FEATURE]:opencode session exportto markdown or json - Discusses exporting session transcripts programmaticallyThese 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.
davidbernat commentedon Jan 26, 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.
github-actions commentedon Jul 6, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.