You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The credentials-server SSH command's stderr showed nested log lines:
```
2026-08-17T05:58:22.088Z DEBUG {"level":"debug","ts":"2026-08-17T05:58:22.087Z","msg":"Wrote docker credentials helper to /usr/local/bin/docker-credential-devsy"}
```
`devsy internal agent container credentials-server` (run remotely over SSH,
see `pkg/tunnel/services.go`) always logs structured JSON on stderr, like every
`devsy internal agent ...` subcommand (`cmd/internal/agent.go` forces
`Format: "json"`). Its stderr was wired to `log.Writer(log.LevelDebug)`,
which treats each captured line as an opaque string and wraps it under the
local logger's own line — nesting one log record inside another.
Fix
Switch `runServicesIteration`'s `Stderr` to `log.PipeJSONStream()`. This
already exists in `pkg/log/jsonstream.go` for exactly this shape of problem
(a devsy subprocess logging its own JSON) and is already used the same way
for `ssh-server` and `container-tunnel` (`pkg/tunnel/container.go`,
`cmd/workspace/ssh.go`). It parses each JSON line from the child process and
re-emits it at its original level and message instead of double-wrapping it.
No new logging component added — this is a one-caller fix to use the
existing pattern consistently.
The credentials-server command run over SSH (devsy internal agent
container credentials-server) always logs structured JSON on stderr,
like other devsy internal agent subcommands. Its stderr was wired to
log.Writer(log.LevelDebug), which wraps each captured line as an
opaque string under the local logger's own format, nesting one log
record inside another.
Switch to log.PipeJSONStream(), the existing mechanism already used
for the same shape of problem in ssh-server and container-tunnel
(pkg/tunnel/container.go, cmd/workspace/ssh.go): it parses each JSON
line and re-emits it at its original level and message.
@skevetter, you've reached your PR review limit, so we couldn't start this review.
Next review available in:5 minutes
Limit details: You’ve used all 1 included review currently available under your plan.
You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.
How can I continue?
After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.
To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.
How do review limits work?
CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.
For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.
AI Reviewer: run a review on demand. To trigger the first review automatically, go to your organization or repository integration settings. AI can make mistakes. Always validate suggestions.
TIP This summary will be updated as you push new changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The credentials-server SSH command's stderr showed nested log lines:
```
2026-08-17T05:58:22.088Z DEBUG {"level":"debug","ts":"2026-08-17T05:58:22.087Z","msg":"Wrote docker credentials helper to /usr/local/bin/docker-credential-devsy"}
```
`devsy internal agent container credentials-server` (run remotely over SSH,
see `pkg/tunnel/services.go`) always logs structured JSON on stderr, like every
`devsy internal agent ...` subcommand (`cmd/internal/agent.go` forces
`Format: "json"`). Its stderr was wired to `log.Writer(log.LevelDebug)`,
which treats each captured line as an opaque string and wraps it under the
local logger's own line — nesting one log record inside another.
Fix
Switch `runServicesIteration`'s `Stderr` to `log.PipeJSONStream()`. This
already exists in `pkg/log/jsonstream.go` for exactly this shape of problem
(a devsy subprocess logging its own JSON) and is already used the same way
for `ssh-server` and `container-tunnel` (`pkg/tunnel/container.go`,
`cmd/workspace/ssh.go`). It parses each JSON line from the child process and
re-emits it at its original level and message instead of double-wrapping it.
No new logging component added — this is a one-caller fix to use the
existing pattern consistently.
Verification