Problem Summary

NongKung remote flow via LINE OA is blocked/inconsistent when GitHub auth and exec behavior differ from assumptions in docs.

Observed from runtime + docs:

• Container .env is owned by root with mode 600 (expected), so node user cannot read it.
• GH_TOKEN may exist in environment, but flow still fails when skill/runtime expects gh auth login or exec path assumptions.
• gh-issues skill docs say primary path is curl + GH_TOKEN (no gh auth login required), but some docs/checklists still imply gh auth login prerequisite.
• Known issue patterns already exist for token invalid (KI-036) and exec host mismatch (KI-010), but remote flow docs are not aligned.

Why this matters

NongKung should be able to run /gh-issues ... from LINE OA without laptop access and without requiring unsafe file permission changes on .env.

Security Note

Do not change .env from 600 to 644 in production-like runtime.

• 644 makes secrets world-readable for all users in the container.
• Correct pattern: inject tokens as environment variables/secrets and consume via process env.

Scope

Standardize and harden remote flow so that:

1. gh-issues works with GH_TOKEN env directly (curl-first path).
2. gh auth login is optional/diagnostic, not a hard requirement.
3. flow survives when exec/tooling has restrictions by providing explicit fallback behavior.

Required Changes

1. Doc alignment (source of truth)

• Update remote-flow docs to state:
  • Primary auth path: GH_TOKEN env + GitHub REST (curl).
  • gh auth status is optional validation only.
  • No recommendation to expose .env by relaxing file mode.
• Align with skill docs that already state curl-first behavior.

2. Runtime auth hardening

• Ensure all GitHub operations in gh-issues and related automation use:
  • Authorization: Bearer $GH_TOKEN
  • explicit 401/403 handling with actionable error.
• If GH_TOKEN missing: clear failure with where to configure it.

3. Exec fallback behavior

• When exec host/policy blocks command execution (e.g., KI-010-like conditions), return a deterministic remediation message:
  • check tools.exec.host
  • check security policy (security.exec / allowlist)
  • avoid silent failure loops.
• For auth-dependent steps, prefer non-interactive env-based flow over interactive gh auth login.

4. NongKung flow checklist update

• Replace prereq item "gh auth login on VPS container" with:
  • GH_TOKEN/GITHUB_TOKEN injection verified
  • curl https://api.github.com/user with Bearer token returns 200
  • optional gh auth status only for diagnostics

5. Regression tests / smoke checks

• Add or update smoke checks covering:
  • valid GH_TOKEN + no gh auth login => /gh-issues --dry-run works
  • missing/invalid token => clear auth error
  • exec restricted => clear remediation guidance, not loop

Acceptance Criteria

• No step in NongKung remote flow requires making .env world-readable.
• /gh-issues ... --dry-run succeeds using env token only.
• Docs no longer conflict on whether gh auth login is mandatory.
• Auth failures and exec restrictions produce explicit, actionable diagnostics.

References

• Openclaw docs: docs/cicd/18-nongkung-remote-dev-flow.md
• Skill: skills/gh-issues/SKILL.md
• Known Issues: KI-036 (gh auth status invalid token), KI-010 (exec host not allowed)

Suggested Labels

• bug
• docs
• security
• scope:ops
• scope:skills