[FEATURE]: Expose session context to child processes via environment variables #9292
Closed as not planned
Description
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
Problem
User scripts and tools that are executed via opencode (bash tool, shell commands) have no way to identify which opencode session they're running in. This makes it difficult to correlate logs, metrics, and outputs when running multiple opencode sessions, such as in iterative workflows (e.g., Ralph loops).
Use Case
A user running a Ralph loop that spawns a new opencode session per iteration needs to log which session each iteration corresponds to. Currently, child processes spawned by opencode have no access to session metadata.
Solution
Expose session context to child processes via environment variables:
OPENCODE_SESSION_ID: The unique identifier of the current session (e.g.,ses_xyz123)OPENCODE_SESSION_TITLE: The human-readable title of the current session (e.g.,"Fix bug in auth flow")
These variables are set in two user-facing command execution contexts:
- Bash tool: When users execute commands via the bash tool
- Prompt shell: When commands are executed via direct shell invocation
Implementation Details
- Environment variables are set dynamically per spawn (not globally at startup like
AGENTandOPENCODE) - This is necessary because users can switch between sessions during interactive work
- Session lookup includes graceful error handling to avoid breaking existing tests and mock contexts
Example Usage
#!/bin/bash
# User script can now access session context
echo "Running in session: $OPENCODE_SESSION_TITLE ($OPENCODE_SESSION_ID)" >> /var/log/opencode-iterations.logThis enables proper tracking and correlation of work across multiple concurrent or sequential opencode sessions.
Activity
github-actions commentedon Jan 18, 2026
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if this specific feature request (session context for bash tool and shell commands) addresses a different use case than these existing issues.
smola commentedon Jan 31, 2026
👍 I also have 2 strong use cases for
OPENCODE_SESSION_ID:tesdal commentedon Feb 15, 2026
With #13661 I guess it would be possible to enable this with your own plugin that populates env, if populating env is more controversial.
jrswab commentedon Feb 27, 2026
+1 on this. I'm hitting the same limitation in practice.
I regularly run multiple concurrent OpenCode sessions in the same project directory. My use case is linking work artifacts (commits, branches, logs) back to the specific session that produced them. Today, the only option from within a session is opencode session list -n 1, which returns the most recently updated session for the working directory. That's unreliable when multiple sessions are active simultaneously.
Having OPENCODE_SESSION_ID (and OPENCODE_SESSION_TITLE) injected into Bash tool subprocesses would make this deterministic. It would also let the LLM itself programmatically interact with its own session via the server API (sharing, exporting, or renaming the session) without guessing which session it belongs to.
github-actions commentedon Apr 29, 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.
wylswz commentedon May 25, 2026
+1. I'm working on an agent that creates pr to my repo and respond to discussions in the same session. I'm trying to wrap the gh cli that builds mapping between pr id and session id, however, it is impossible to do this currently. Having session id propagated would be really helpful.