{"version":"2.1.288","anchor":"gh-shim-reworked-for-hosted-sessions-and-enclosing-shims","canonical_anchor":"gh-shim-reworked-for-hosted-sessions-and-enclosing-shims","heading":"How remote sessions set up their stand-in gh command","tier":"internal","area":"Sessions","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.288\/e\/gh-shim-reworked-for-hosted-sessions-and-enclosing-shims","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.288","markdown":"### How remote sessions set up their stand-in `gh` command\n\nIn remote sessions, the stand-in `gh` command now gets its own folder per session, is skipped in some cases and cleans itself up\n\n**Unclear.** It is not clear what sets the session identifier that selects the per-session setup.\n\n**What**\n\nIn remote sessions (with `CLAUDE_CODE_REMOTE` set and the agent proxy turned on), Claude Code can put in place a stand-in `gh` command, a small program that takes the place of the GitHub command-line tool. This is set up differently now:\n\n- Each session gets its own folder under `sessions\/`, instead of all sharing one folder.\n\n- In selective relay mode, where GitHub requests are not sent through the session's proxy, no stand-in is created if `gh` is not already installed.\n\n- If an outer session already set up its own stand-in, Claude Code leaves it alone.\n\n- The stand-in file is deleted by a cleanup step when it is no longer needed.\n\n- When the `gh` in use is not the stand-in, the note Claude reads says it is the machine's own GitHub CLI.\n\n**Why**\n\nThis changes how `gh` behaves inside remote sessions, and Claude is told more accurately which `gh` it is using.\n\n- Area: Sessions\n- Names: `CLAUDE_CODE_REMOTE`\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}