Bug: Forked sessions show same session ID as pm-agent + delegate without args shows wrong error #81

New Issue

shoko · 2026-04-01T23:56:22+02:00

shoko commented

2026-04-01 23:56:22 +02:00

Bug Description

Two bugs observed when running kugetsu delegate for a new issue:

Bug 1: Forked session shows same session ID as pm-agent

Steps to reproduce:

# Clean state: 1 base session + 1 pm-agent session (2 sessions total)
kugetsu list
# Shows: base (ses_xxx), pm-agent (ses_yyy)

# Delegate a new issue
kugetsu delegate "owner/repo#2 - task description"
# Output shows worktree created, fork attempted, but "Error: Session not found"
# Then: "Session started for 'owner/repo#2': ses_yyy"
#       (same ID as pm-agent!)

kugetsu list
# Shows: base, pm-agent, forked-issue — but forked-issue has SAME session ID as pm-agent

Expected: Forked session should have its own unique session ID (e.g., ses_zzz).

Actual: Forked session shows ses_yyy which is the pm-agent's session ID. This means both the pm-agent and the forked issue appear to share the same session.

Likely cause: In cmd_start(), the session ID detection loop finds the pm-agent's session first (or the pm-agent session shares the same ID after fork):

while IFS= read -r sess; do
    if [[ ! "$before_set" =~ \|${sess}\| ]] && [[ "$sess" != "$base_session_id" ]]; then
        new_session_id="$sess"
        break
    fi
done <<< "$after_sessions"

The pm-agent was forked from the base session, so it appears in after_sessions but not in before_set. The condition [[ "$sess" != "$base_session_id" ]] is true for the pm-agent, so it gets assigned as the new session ID.

Bug 2: `kugetsu delegate` without arguments shows opencode help instead of error

Steps to reproduce:

kugetsu delegate

Expected: Error message like "Error: message is required" or "Usage: kugetsu delegate "

Actual: Prints opencode CLI help text (opencode's own help, not kugetsu's).

Likely cause: When kugetsu delegate is called without arguments, the cmd_delegate function calls kugetsu delegate with no message, but the shell appears to route it to opencode run which prints its help.

Actually looking at the code more carefully:

cmd_delegate() {
    local message="${1:-}"
    if [ -z "$message" ]; then
        echo "Error: message is required" >&2
        exit 1
    fi
    ...
}

When called as kugetsu delegate with no message at all (positional args), message would be empty and should print the error. But the actual output was opencode help. This might be a shell parsing issue where $1 isn't being passed correctly when the command is run without subshell.

Environment

kugetsu version: latest (from ~/.local/bin/kugetsu)
OS: Linux
opencode: available in PATH
Session count before delegate: 2 (base + pm-agent)

Severity

Medium — the session ID bug means forked issue sessions are not properly isolated from the pm-agent. The delegate command still "works" in that it creates worktrees and triggers opencode, but session tracking is broken.

Files affected

~/.local/bin/kugetsu — the main script
cmd_start() function — session detection after fork
cmd_delegate() function — argument handling

## Bug Description Two bugs observed when running `kugetsu delegate` for a new issue: ### Bug 1: Forked session shows same session ID as pm-agent **Steps to reproduce:** ```bash # Clean state: 1 base session + 1 pm-agent session (2 sessions total) kugetsu list # Shows: base (ses_xxx), pm-agent (ses_yyy) # Delegate a new issue kugetsu delegate "owner/repo#2 - task description" # Output shows worktree created, fork attempted, but "Error: Session not found" # Then: "Session started for 'owner/repo#2': ses_yyy" # (same ID as pm-agent!) kugetsu list # Shows: base, pm-agent, forked-issue — but forked-issue has SAME session ID as pm-agent ``` **Expected:** Forked session should have its own unique session ID (e.g., `ses_zzz`). **Actual:** Forked session shows `ses_yyy` which is the pm-agent's session ID. This means both the pm-agent and the forked issue appear to share the same session. **Likely cause:** In `cmd_start()`, the session ID detection loop finds the pm-agent's session first (or the pm-agent session shares the same ID after fork): ```bash while IFS= read -r sess; do if [[ ! "$before_set" =~ \|${sess}\| ]] && [[ "$sess" != "$base_session_id" ]]; then new_session_id="$sess" break fi done <<< "$after_sessions" ``` The pm-agent was forked from the base session, so it appears in `after_sessions` but not in `before_set`. The condition `[[ "$sess" != "$base_session_id" ]]` is true for the pm-agent, so it gets assigned as the new session ID. ### Bug 2: `kugetsu delegate` without arguments shows opencode help instead of error **Steps to reproduce:** ```bash kugetsu delegate ``` **Expected:** Error message like "Error: message is required" or "Usage: kugetsu delegate <message>" **Actual:** Prints opencode CLI help text (opencode's own help, not kugetsu's). **Likely cause:** When `kugetsu delegate` is called without arguments, the `cmd_delegate` function calls `kugetsu delegate` with no message, but the shell appears to route it to `opencode run` which prints its help. Actually looking at the code more carefully: ```bash cmd_delegate() { local message="${1:-}" if [ -z "$message" ]; then echo "Error: message is required" >&2 exit 1 fi ... } ``` When called as `kugetsu delegate` with no message at all (positional args), `message` would be empty and should print the error. But the actual output was opencode help. This might be a shell parsing issue where `$1` isn't being passed correctly when the command is run without subshell. ### Environment - kugetsu version: latest (from ~/.local/bin/kugetsu) - OS: Linux - opencode: available in PATH - Session count before delegate: 2 (base + pm-agent) ### Severity Medium — the session ID bug means forked issue sessions are not properly isolated from the pm-agent. The delegate command still "works" in that it creates worktrees and triggers opencode, but session tracking is broken. ### Files affected - `~/.local/bin/kugetsu` — the main script - `cmd_start()` function — session detection after fork - `cmd_delegate()` function — argument handling

shoko added the task-delegation label 2026-04-02 00:30:42 +02:00

shoko commented

2026-04-02 00:35:46 +02:00

Clarifying Questions

I reviewed this issue and have some questions:

Bug 1 (session ID collision):

I see that cmd_delegate (lines 509-529) sends a message to the existing PM agent via opencode run --continue --session "$pm_session" - it does NOT create a new forked session. A new session is only created by cmd_start.

But the output you showed indicates Session started for "owner/repo#2": ses_yyy which comes from cmd_start, not cmd_delegate.

Can you clarify: is the bug happening when you call kugetsu start directly, or is there a code path where cmd_delegate calls cmd_start?

Bug 2 (delegate without args):

The current code already has this check:

if [ -z "$message" ]; then
    echo "Error: message is required" >&2
    echo "Usage: kugetsu delegate <message>" >&2
    exit 1
fi

Has this been fixed already, or are you seeing different behavior?

Additional context:

The issue title mentions "forked sessions show same session ID as pm-agent" - can you confirm if:

Both sessions actually have the same session ID stored?
Or is it that kugetsu list shows the same ID for both?

## Clarifying Questions I reviewed this issue and have some questions: **Bug 1 (session ID collision):** I see that `cmd_delegate` (lines 509-529) sends a message to the existing PM agent via `opencode run --continue --session "$pm_session"` - it does NOT create a new forked session. A new session is only created by `cmd_start`. But the output you showed indicates `Session started for "owner/repo#2": ses_yyy` which comes from `cmd_start`, not `cmd_delegate`. Can you clarify: is the bug happening when you call `kugetsu start` directly, or is there a code path where `cmd_delegate` calls `cmd_start`? **Bug 2 (delegate without args):** The current code already has this check: ```bash if [ -z "$message" ]; then echo "Error: message is required" >&2 echo "Usage: kugetsu delegate <message>" >&2 exit 1 fi ``` Has this been fixed already, or are you seeing different behavior? **Additional context:** The issue title mentions "forked sessions show same session ID as pm-agent" - can you confirm if: 1. Both sessions actually have the same session ID stored? 2. Or is it that `kugetsu list` shows the same ID for both?

shoko commented

2026-04-02 00:39:36 +02:00

Replies

Bug 1 (session ID collision):

cmd_delegate DOES call cmd_start when an issue ref is found in the message. My message was:

git.fbrns.co/shoko/jigaido#2 - Revise PR #3...

This matches the short ref pattern and cmd_start was called. The sequence was:

I called kugetsu delegate "git.fbrns.co/shoko/jigaido#2 - ..."
cmd_delegate extracted issue ref git.fbrns.co/shoko/jigaido#2
Since issue ref was found → cmd_start was called
cmd_start forked from base session (ses_2b7b405...)
New session should have been detected, but instead ses_2b7a817 (the pm-agent's session) was returned
Worktree created at correct path, but session ID was wrong

The root cause you identified is likely correct — the pm-agent was forked from base earlier and appears in after_sessions but not in before_set, so it gets picked up as "new."

To confirm: kugetsu list showed the forked issue AND pm-agent sharing the same session ID (ses_2b7a817daffeaQGNzKDT5q1F3t).

Bug 2 (delegate without args):

The code has the check but when I ran kugetsu delegate (without any arguments), it printed opencode help instead of the error. I did NOT pass $1 — I literally ran kugetsu delegate with no arguments at all. The check if [ -z "$message" ] where message="${1:-}" should have caught this, but it seems like the shell is routing to opencode run with no message argument which then shows its own help.

So both issues are confirmed. The session ID bug makes delegation unusable for new issues. The delegate-without-args bug is a minor UX issue.

Summary:

Bug 1: Confirmed — forked sessions show same ID as pm-agent in kugetsu list
Bug 2: Confirmed — kugetsu delegate with no args shows opencode help instead of kugetsu error

## Replies **Bug 1 (session ID collision):** `cmd_delegate` DOES call `cmd_start` when an issue ref is found in the message. My message was: ``` git.fbrns.co/shoko/jigaido#2 - Revise PR #3... ``` This matches the short ref pattern and `cmd_start` was called. The sequence was: 1. I called `kugetsu delegate "git.fbrns.co/shoko/jigaido#2 - ..."` 2. `cmd_delegate` extracted issue ref `git.fbrns.co/shoko/jigaido#2` 3. Since issue ref was found → `cmd_start` was called 4. `cmd_start` forked from base session (ses_2b7b405...) 5. New session should have been detected, but instead `ses_2b7a817` (the pm-agent's session) was returned 6. Worktree created at correct path, but session ID was wrong The root cause you identified is likely correct — the pm-agent was forked from base earlier and appears in `after_sessions` but not in `before_set`, so it gets picked up as "new." To confirm: `kugetsu list` showed the forked issue AND pm-agent sharing the same session ID (`ses_2b7a817daffeaQGNzKDT5q1F3t`). **Bug 2 (delegate without args):** The code has the check but when I ran `kugetsu delegate` (without any arguments), it printed opencode help instead of the error. I did NOT pass `$1` — I literally ran `kugetsu delegate` with no arguments at all. The check `if [ -z "$message" ]` where `message="${1:-}"` should have caught this, but it seems like the shell is routing to `opencode run` with no message argument which then shows its own help. So both issues are confirmed. The session ID bug makes delegation unusable for new issues. The delegate-without-args bug is a minor UX issue. **Summary:** - Bug 1: Confirmed — forked sessions show same ID as pm-agent in `kugetsu list` - Bug 2: Confirmed — `kugetsu delegate` with no args shows opencode help instead of kugetsu error

shoko referenced this issue from a commit

2026-04-02 01:04:17 +02:00

fix: session ID collision in cmd_start + delegate issue ref extraction

shoko referenced a pull request that will close this issue

2026-04-02 01:04:39 +02:00

fix: session ID collision in cmd_start + delegate issue ref extraction #82

shoko referenced this issue from a commit

2026-04-02 01:36:00 +02:00

fix: session ID collision in cmd_start by excluding pm_agent_session_id

shoko referenced this issue from a commit

2026-04-02 01:43:19 +02:00

fix: use array-based session detection for robust concurrent fork handling