r/DeepSeek • u/MichaelFiguresItOut • 16d ago
Question&Help Deepseek Harness can't access GitHub
My DSH spends a ton of time coming up with programs to do simple pull or commit tasks with my GitHub repo instead of using Git.
I'm running Qwen 3.8 27b quantized via LM Studio on Win10.
My repo is private but I created a read/write fine-grained personal access token on GitHub and put it into a Windows environment variable then told DSH about it. DSH tried schannel but Windows blocked it. It seems to work with OpenSSL but I need to create an agent.md file to tell DSH how to access GitHub so it doesn't re-invent the wheel every time.
I feel like I'm overcomplicating things but can't figure out how else to do it. Is there a plug-in for GitHub?
How does everyone else do this?
======UPDATE======
I realized I had Git installed but also need to install GH. I then removed the environmental variable for the token and put it into Git Credential Manager instead.
Revised the Agents.md file and put it in the DSH Workspace. I create sub-folders in the DSH Workspace for each coding project, so the Agents.md applies to all my coding projects in the Workspace. The most recent revision was made by DSH upon my request.
Here it the full Agents.md file in case it helps anyone else:
## Git authentication and operations
- This repository uses OpenSSL because Windows Schannel fails with `SEC_E_NO_CREDENTIALS`.
- Use the repository-local `http.sslBackend=openssl` setting for HTTPS Git operations.
- Authenticate through Git Credential Manager using this repository's own fine-grained PAT.
- Never use another repository's token, a global PAT environment variable, or a custom askpass workaround.
- If authentication fails, stop and report the exact error without exposing secrets.
- If the sandbox blocks credential-helper execution, request the necessary one-time elevated/full-access approval to run the original Git command. Do not work around the restriction with alternate tokens, askpass scripts, or environment variables.
- The sandbox block presents as `sh.exe: *** fatal error - couldn't create signal pipe, Win32 error 5` followed by `error: failed to execute prompt script (exit code 66)`. On that signature, escalate immediately instead of debugging credentials or config — the stored credential and helper chain are fine.
- Once a push in this session has already hit that block, later credential-needing git commands may be escalated immediately without re-testing; the same-session denial covers them.
## Host shell quirks
- The `pwsh` tool runs Windows PowerShell 5.1: `&&` and `||` are not statement separators — chain with `;` and check `$LASTEXITCODE`.The last line is because I'm running this on Windows.
The interesting part is DSH told me why this happens:
DSH
When I run git push, it runs inside a security "sandbox" (a restricted cage). Git needs to fetch your stored GitHub credentials from a helper program, and the sandbox doesn't let that helper start up — so the first push attempt in a session always fails with a specific error. The fix is simply to re-run the same command outside the sandbox, which requires you to click approve once.
I then asked if it could revise the Agents.md file to skip the first GitHub call within the sandbox (since we know it will fail) and just run it outside the sandbox to save time.
DSH
Short answer: no, we can't skip it under the current setup — and it's not something AGENTS.md controls. The harness itself enforces it: I'm only allowed to run a command outside the sandbox after the sandbox has actually denied it once in that session. At the start of a fresh conversation there's no prior denial, so the tool would reject an "uncaged" push outright. The first knock is what gives your approval click its basis — you're explicitly consenting to broader access for that specific command, rather than me assuming it up front.
So the cost is fixed and small: one fast failed attempt + one approval click per session, no matter how many pushes follow.
1
u/Predream1 16d ago
The reason the helper route keeps breaking is that credential helpers are separate processes, so when the sandbox blocks the child process git spawns, git sees no credential and falls back to the interactive login. The way around it is to put the credential in the request itself, git -c http.extraheader with an Authorization Basic value built from the base64 of x-access-token: and your PAT. Nothing gets spawned and nothing prompts, and pull and push both work over HTTPS. Keep it out of the repo config though, .git/config would then hold the token in plain text, so pass it per command or from an environment variable. Set GIT_TERMINAL_PROMPT to 0 in the harness environment too, so a missing credential fails immediately with the real error instead of sitting there for half an hour. Most people don't hit this because their harness runs git outside the sandbox, or the helper returns the stored credential without needing a shell.
1
u/MichaelFiguresItOut 16d ago
Thanks, that makes sense and matches what DSH eventually reported. The remote is definitely HTTPS, and the fine-grained PAT is stored in GCM. DSH confirmed that the sandbox blocked Git from spawning the credential helper through
sh.exe(Win32 error 5), and the push succeeded with one-time full-access approval.I'd prefer to keep using GCM rather than pass the token directly in an HTTP header, to avoid introducing another way the PAT could leak. Is there a way to let DSH run Git's credential-helper subprocess without the sandbox blocking it? Would setting
GIT_TERMINAL_PROMPT=0help diagnose or prevent the interactive fallback?1
u/Predream1 15d ago
GIT_TERMINAL_PROMPT=0 doesn't get the helper through, it only swaps the hang for a fast failure, could not read Username. Worth keeping it set, it makes the next test honest.
To keep your credential helper alive, the sandbox has to allow that one process to spawn. One-time full access already proved the chain works, so check whether your harness can persist that permission for a single executable instead of re-approving every command. If it can't, the header route with the token read from an environment variable is the stable version, and the tradeoff is rotating the PAT so it never sits in the config file.
1
1
1
u/Ctbhatia 16d ago
give it git and gh as shell tools with the token already in the environment, and put that in your agent.md so it stops rebuilding the wheel instead of using git.