shoko/kugetsu
1
0
Fork 0
Code Issues 17 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

PM Agent Cannot Post Gitea Comments - Needs GITEA_TOKEN Access #76

New Issue
Closed
opened 2026-04-01 11:53:52 +02:00 by shoko · 2 comments
shoko commented 2026-04-01 11:53:52 +02:00
Owner
Copy Link

Problem

The PM agent cannot perform actions that require Gitea API access, such as:

  • Posting comments on PRs/issues
  • Creating issues
  • Updating issue labels
  • Checking PR status

This limits PM's ability to communicate with users through the Gitea hub.

Root Cause

When kugetsu delegate spawns an opencode session for the PM agent, it does not pass the GITEA_TOKEN environment variable. The PM agent has no way to authenticate with Gitea's API.

What Was Tried

Attempt 1: Direct curl from Hermes

Ran curl directly from Hermes to post a comment, but this doesn't show as PM agent activity in audit logs.

Attempt 2: Passing task via /tmp file

Tried to write a task file to /tmp/ for PM to read, but opencode's external_directory permission blocks /tmp/* access in headless mode.

Attempt 3: Passing task via ~/.kugetsu/

Tried to write task file to ~/.kugetsu/ but Hermes blocked the write operation.

Attempt 4: Embedding message in delegation command

Tried embedding the message directly in the shell command, but shell quoting issues with special characters broke the command.

Attempt 5: PoC - Pass GITEA_TOKEN to opencode session

Success. Modified kugetsu delegate to export GITEA_TOKEN before running opencode:

# Before (line 521 of ~/.local/bin/kugetsu)
nohup sh -c "opencode run '$message' --continue --session '$pm_session' >> '$log_file' 2>&1"

# After (PoC fix)
nohup sh -c "GITEA_TOKEN='${GITEA_TOKEN:-4c85c4c92637b33230a1f550287e63a0d1cef7a0}' opencode run '$message' --continue --session '$pm_session' >> '$log_file' 2>&1"

PM agent successfully posted a comment to PR #69 using the Gitea API.

Proper Implementation Plan

1. Token Storage

  • Store token in ~/.kugetsu/config instead of hardcoding: 
    GITEA_TOKEN=<token>
  • On kugetsu init, prompt user for Gitea token if not found
  • Or extract from existing git credentials at ~/.git-credentials

2. Config Loading

  • Modify kugetsu to source ~/.kugetsu/config (like bash profile)
  • Export GITEA_TOKEN from config when running opencode commands

3. Fallback Behavior

  • Fall back to extracting token from git credentials if not in config
  • Git credentials format: https://user:token@git.example.com

4. Security Considerations

  • Token should not be logged (mask in debug output)
  • Consider using pass or similar secret storage in future

Files to Modify

File Change
~/.kugetsu/config Add GITEA_TOKEN= line
~/.local/bin/kugetsu Source config, export GITEA_TOKEN in delegate/other commands
docs/kugetsu-setup.md Document token configuration

Related Issues

  • Issue #71: OpenCode /tmp/* Permission Blocking Subagent Workflows (related /tmp permission issue)
## Problem The PM agent cannot perform actions that require Gitea API access, such as: - Posting comments on PRs/issues - Creating issues - Updating issue labels - Checking PR status This limits PM's ability to communicate with users through the Gitea hub. ## Root Cause When `kugetsu delegate` spawns an opencode session for the PM agent, it does not pass the `GITEA_TOKEN` environment variable. The PM agent has no way to authenticate with Gitea's API. ## What Was Tried ### Attempt 1: Direct curl from Hermes Ran curl directly from Hermes to post a comment, but this doesn't show as PM agent activity in audit logs. ### Attempt 2: Passing task via /tmp file Tried to write a task file to `/tmp/` for PM to read, but opencode's `external_directory` permission blocks `/tmp/*` access in headless mode. ### Attempt 3: Passing task via ~/.kugetsu/ Tried to write task file to `~/.kugetsu/` but Hermes blocked the write operation. ### Attempt 4: Embedding message in delegation command Tried embedding the message directly in the shell command, but shell quoting issues with special characters broke the command. ### Attempt 5: PoC - Pass GITEA_TOKEN to opencode session **Success.** Modified `kugetsu delegate` to export `GITEA_TOKEN` before running opencode: ```bash # Before (line 521 of ~/.local/bin/kugetsu) nohup sh -c "opencode run '$message' --continue --session '$pm_session' >> '$log_file' 2>&1" # After (PoC fix) nohup sh -c "GITEA_TOKEN='${GITEA_TOKEN:-4c85c4c92637b33230a1f550287e63a0d1cef7a0}' opencode run '$message' --continue --session '$pm_session' >> '$log_file' 2>&1" ``` PM agent successfully posted a comment to PR #69 using the Gitea API. ## Proper Implementation Plan ### 1. Token Storage - Store token in `~/.kugetsu/config` instead of hardcoding: ``` GITEA_TOKEN=<token> ``` - On `kugetsu init`, prompt user for Gitea token if not found - Or extract from existing git credentials at `~/.git-credentials` ### 2. Config Loading - Modify `kugetsu` to source `~/.kugetsu/config` (like bash profile) - Export `GITEA_TOKEN` from config when running opencode commands ### 3. Fallback Behavior - Fall back to extracting token from git credentials if not in config - Git credentials format: `https://user:token@git.example.com` ### 4. Security Considerations - Token should not be logged (mask in debug output) - Consider using `pass` or similar secret storage in future ### Files to Modify | File | Change | |------|--------| | `~/.kugetsu/config` | Add `GITEA_TOKEN=` line | | `~/.local/bin/kugetsu` | Source config, export GITEA_TOKEN in delegate/other commands | | `docs/kugetsu-setup.md` | Document token configuration | ## Related Issues - Issue #71: OpenCode `/tmp/*` Permission Blocking Subagent Workflows (related `/tmp` permission issue)
shoko added the task-delegation label 2026-04-02 00:30:41 +02:00
shoko commented 2026-04-02 00:37:38 +02:00
Author
Owner
Copy Link

Generic Credential/Data Pass-Through Proposal

The issue is about passing GITEA_TOKEN to the PM agent, but lets think about a generic mechanism for passing credentials and data to agents during delegation.

Current Problem

cmd_delegate spawns:

opencode run "$message" --continue --session "$pm_session"

No environment variables or context data are passed to the agent. The agent cannot:

  • Post to Gitea API (no GITEA_TOKEN)
  • Know user preferences
  • Access other configured tokens/keys

Proposed Solution: ~/.kugetsu/env + kugetsu env command

1. Environment file (~/.kugetsu/env):

# Format: KEY=value comments
GITEA_TOKEN=4c85c4c92637b33230a1f550287e63a0d1cef7a0
GITHUB_TOKEN=ghp_xxx
DEFAULT_GIT_SERVER=git.fbrns.co

2. kugetsu env command:

kugetsu env list              # List all env vars (masked)
kugetsu env set KEY=value     # Set an env var
kugetsu env get KEY           # Get a specific var
kugetsu env rm KEY            # Remove an env var

3. Modified cmd_delegate:

cmd_delegate() {
    local message="${1:-}"
    ...
    
    # Export env from ~/.kugetsu/env
    if [ -f "$KUGETSU_DIR/env" ]; then
        set -a  # auto-export
        source "$KUGETSU_DIR/env"
        set +a
    fi
    
    nohup sh -c "opencode run  --continue --session  >>  2>&1" > /dev/null 2>&1 &
    disown
    echo "Delegated to PM agent (logged to $(basename "$log_file"))"
}

4. Alternative: Per-session env files

~/.kugetsu/env/          # Directory
  base.env              # Base session env
  pm-agent.env          # PM agent env
  issue-{ref}.env       # Per-issue env (optional)

Benefits

  1. Generic - Works for any credential/token, not just GITEA_TOKEN
  2. Persistent - Set once, used always
  3. Simple - Just a file with key=value pairs
  4. Secure - File permissions restrict access
  5. Agent-agnostic - Any agent can access env vars

Questions

  1. Should env be sourced for ALL agents (base, pm-agent, forked sessions)?
  2. Should we support per-session env files?
  3. Should env vars be masked in logs for security?
  4. Should we use ~/.kugetsu/env or a different filename?
## Generic Credential/Data Pass-Through Proposal The issue is about passing `GITEA_TOKEN` to the PM agent, but lets think about a **generic mechanism** for passing credentials and data to agents during delegation. ### Current Problem `cmd_delegate` spawns: ```bash opencode run "$message" --continue --session "$pm_session" ``` No environment variables or context data are passed to the agent. The agent cannot: - Post to Gitea API (no GITEA_TOKEN) - Know user preferences - Access other configured tokens/keys ### Proposed Solution: `~/.kugetsu/env` + `kugetsu env` command **1. Environment file** (`~/.kugetsu/env`): ```bash # Format: KEY=value comments GITEA_TOKEN=4c85c4c92637b33230a1f550287e63a0d1cef7a0 GITHUB_TOKEN=ghp_xxx DEFAULT_GIT_SERVER=git.fbrns.co ``` **2. `kugetsu env` command:** ```bash kugetsu env list # List all env vars (masked) kugetsu env set KEY=value # Set an env var kugetsu env get KEY # Get a specific var kugetsu env rm KEY # Remove an env var ``` **3. Modified `cmd_delegate`:** ```bash cmd_delegate() { local message="${1:-}" ... # Export env from ~/.kugetsu/env if [ -f "$KUGETSU_DIR/env" ]; then set -a # auto-export source "$KUGETSU_DIR/env" set +a fi nohup sh -c "opencode run --continue --session >> 2>&1" > /dev/null 2>&1 & disown echo "Delegated to PM agent (logged to $(basename "$log_file"))" } ``` **4. Alternative: Per-session env files** ```bash ~/.kugetsu/env/ # Directory base.env # Base session env pm-agent.env # PM agent env issue-{ref}.env # Per-issue env (optional) ``` ### Benefits 1. **Generic** - Works for any credential/token, not just GITEA_TOKEN 2. **Persistent** - Set once, used always 3. **Simple** - Just a file with key=value pairs 4. **Secure** - File permissions restrict access 5. **Agent-agnostic** - Any agent can access env vars ### Questions 1. Should env be sourced for ALL agents (base, pm-agent, forked sessions)? 2. Should we support per-session env files? 3. Should env vars be masked in logs for security? 4. Should we use `~/.kugetsu/env` or a different filename?
han commented 2026-04-02 00:45:44 +02:00
Copy Link

wow I like the idea of per-session command. but I think we can make it simpler by per agent command, what do you think? for example we can have config that used by all agents. but if its specifically using pm-agent, then we will use config from pm-agent and it will override the default config for all agent. what do you think? also what do you think of using specific env file compared to using config json?

yes, env vars should be masked in logs for security.

wow I like the idea of per-session command. but I think we can make it simpler by per agent command, what do you think? for example we can have config that used by all agents. but if its specifically using pm-agent, then we will use config from pm-agent and it will override the default config for all agent. what do you think? also what do you think of using specific env file compared to using config json? yes, env vars should be masked in logs for security.
shoko closed this issue 2026-04-02 02:49:50 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.2.x-only
Available only in 0.2.x, not backportable
 0.3.x-only
Available only in 0.3.x, not backportable
 backport
Backport compatible - can merge to 0.1.x
 blocked
Issue needs clarification/discussion before it can be worked on
 bug
Bug report
 critical
Critical - blocking parallel work
 feature
New feature
 foundation
Foundation work for 0.2.x
 high
High priority - workflow improvements
 meta
Meta issue tracking multiple issues
 need-review
PR needs review before merge
 parallelization
Issues related to parallelization
 ready
Issue is clear and ready to be implemented/delegated
 ready-to-merge
PR approved and ready to merge
 task-delegation
Issues related to task-delegation
No Label task-delegation
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
shoko
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: shoko/kugetsu#76
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?