Repository navigation
fix(fork): session create silently ignores ?directory= — honor it or reject loudly #1360
Description
Found in the access-pattern benchmark (code#1344), 2026-10-27: POST /api/session?directory=/tmp/oc-bench-work returned a session whose location was /home/user — the query param is silently ignored; location only takes effect via the JSON body ({"location": {"directory": ...}}). The silent fallback ran a tool-enabled session in the account home directory and wrote a file there (f1.txt in /home/user) before the cause was spotted.
Fork: developing-today/opencode v2 API. Fix options, in preference order: honor ?directory= on session create for parity with the body's location; or return a 400 when an unknown/ineffective directory param is supplied. Silent fallback to the server's home is the one unacceptable behavior. Cover with a server test: create with the query param, assert the session location (or the 400).
Acceptance: no API path can produce a session in an unintended directory without an explicit, visible signal.
Acceptance criteria
- No API path can produce a session in an unintended directory without an explicit signal: POST /api/session either honors ?directory= (parity with the body's location) or returns a 400 for the ineffective parameter.
- A server regression test covers session create with the query param and asserts the session location (or the 400).
- The silent fallback to the server's home directory is gone.
Activity
developing-today commentedon Oct 27, 2026
CODE-460
dezren39 commentedon Oct 27, 2026
Intake review
Safety-relevant silent fallback: ?directory= on session create is ignored and the session lands in the account home directory — a tool-enabled session already wrote a file there during the benchmark. Preference order in the issue: honor the param, else reject loudly. Priority set high for the silent-wrong-directory failure mode.
Related: Related: #1344 (benchmark that found it); fork repo developing-today/opencode (v2 API) is where the fix lands. Labels normalized by fleet monitor: the issue arrived with only meta/follow-up.
Still live: checked this run — no merged PR in the recent merged list of this repo implements or resolves this issue, and no closing reference was found; the issue stays open.
🤖 Agent note · filed
12 remaining items
developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 7234 (triage, queued, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
dezren39 commentedon Nov 3, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 3, 2026
🤖 Agent note · done
Triage findings — bug confirmed at current opencode main; fix filed in the opencode repo
Verified fresh this pass against
developing-today/opencodemaine57af295bb:packages/protocol/src/groups/session.ts: thesession.createendpoint (POST /api/session) declares no query schema —?directory=is not a declared parameter and is dropped without a signal. Its payload offers onlylocation.packages/server/src/handlers/session.ts: the handler falls back tolocation ?? { directory: process.cwd() }— exactly the silent fallback to the server's working directory the issue reports.session.list'sSessionsQuerydoes declaredirectory, so callers reasonably expect create to accept it.Fix path (per this issue's own cross-repo direction): filed as developing-today-forks/opencode#1570 with the file:line evidence, the preference order (honor
?directory=for parity with bodylocation, or 400 loudly), and acceptance criteria including the server regression test.This issue stays open as the record of the set (origin: access-pattern benchmark, issue #1344) and closes when opencode#1570 lands. No blockers on this side.