OpenCode sessions can finish before Daytona returns the Git changes

[geoff-ux]

Describe the bug

We are building an internal coding agent on top of OpenCode. OpenCode stays on our trusted host, and Daytona provides the isolated computer where the repository tools run.

The remote file and shell tools work well, and we were able to resume the same sandbox after restarting OpenCode. The blocker is the Git return path.

When an OpenCode session becomes idle, the Daytona plugin starts autoCommitAndPull(). The Daytona handler awaits that work internally, but OpenCode dispatches generic plugin events without awaiting the returned promise. The plugin also catches sync failures and only writes them to its own log. As a result, a host can receive the terminal session.idle event and close the run before the Daytona changes have reached the local Git repository.

In our live test, the coding turn finished successfully while the Git handoff was still running. That makes it impossible for a supervisor to distinguish “the agent finished and the change is safely back” from “the model finished but Git is still pending or failed.”

Current source:

• Daytona starts the Git handoff from the idle event
• OpenCode dispatches generic event hooks without awaiting them

Which package or app?

packages/opencode-plugin, published as @daytona/opencode@0.191.0.

To Reproduce

1. Start OpenCode 1.18.16 in a normal Git worktree with @daytona/opencode@0.191.0.
2. Let the plugin create a sandbox and have OpenCode change a tracked file through the Daytona tools.
3. Observe the session.idle event from the host and treat it as the end of the coding turn.
4. Exit or close the supervised run immediately after that event.
5. The local opencode/N branch may not contain the sandbox change yet. If the Git handoff fails, the failure is logged by the plugin but is not returned to the caller that observed the completed turn.

We also hit two related problems on this path:

1. The first noninteractive Git sync stopped at SSH host verification for ssh.app.daytona.io. The integration did not provide a trusted host-key path that our supervisor could verify without trust on first use.
2. The plugin binds tools and session events to ctx.project.worktree, even though OpenCode provides the active ctx.worktree. In a linked-worktree setup, this can select a previously persisted checkout instead of the active one. See session events, custom tools, and OpenCode's plugin context.

Expected behavior

The native integration should provide one completion boundary that a host can await and that:

1. Does not report success until the sandbox commit has reached the intended local worktree.
2. Returns a Git failure to the host in a structured way.
3. Uses the active OpenCode worktree.
4. Supports noninteractive, independently verifiable SSH host trust.

This does not need to be tied to session.idle if OpenCode's event contract cannot provide that guarantee. An explicit native sync operation or another official lifecycle hook would also work, as long as the result is observable and failure-bearing.

Screenshots

Not applicable. The public source links and steps above reproduce the lifecycle gap.

Environment

• Package/app + version: @daytona/opencode@0.191.0
• Daytona SDK version: @daytona/sdk@0.163.0
• OpenCode version: 1.18.16
• Runtime: Node.js 24.15.0
• Host OS: macOS 26.5.2

Additional context

A clean install of @daytona/opencode@0.191.0 currently reports 5 high vulnerabilities through @daytona/sdk@0.163.0 when run with npm audit --audit-level=high, with fixAvailable: false. We did not include security-sensitive Git credential details here because this repository's security policy asks for those to be reported privately.

Happy to help test a candidate release against the full create, edit, return, resume, and cleanup lifecycle.

[mislavivanda]

Hey @geoff-ux, thanks for lifting the issue and detailed explanations.

All parts of the issue have been implemented and published in the newest 0.192.0 version of the package.

Please upgrade to the newest version and report if everything is fixed so we can close this issue.

[geoff-ux]

Thanks for turning this around so quickly. We tested the exact published @daytona/opencode@0.192.0 artifact.

There is real progress:

• The new gitSync tool is awaitable and returns its own Git errors.
• Normal tools and session sync now use the active OpenCode worktree.
• The SDK upgrade worked. A fresh production install now reports zero npm audit vulnerabilities.
• The npm tarball matches the registry integrity metadata and the 0.192.0 release commit.

We still cannot safely enable the plugin for supervised coding runs because three lifecycle gaps remain.

1. gitSync is reliable only when the model explicitly calls it and the host verifies that exact tool result. Initial Git setup and push failures are still caught and followed by a successful sandbox return. Idle-sync failures are logged only, and graceful disposal logs and succeeds after its 60-second drain limit. Those paths can still look successful without a completed Git return.
2. Worktree state is stored once per project, not per session. Each session access overwrites that project-level value. A final sync during deletion can therefore return session A through session B's most recently stored linked worktree.
3. DAYTONA_SSH_KNOWN_HOSTS gives us strict verification once a trusted key is available, but we still cannot find an authoritative published fingerprint or SSHFP record. The optional gateway public-key field was not present in the live configuration, the SDK does not expose a public getter for it, and the plugin does not consume it.

Relevant released source:

• Git initialization failure is caught before the successful sandbox return
• The stored worktree remains project-level
• Known-host setup still requires an unspecified out-of-band verification step

We also updated the existing private advisory with the 0.192.0 credential-handling evidence, so I will keep those details there.

Could you please keep this issue open? We are happy to repeat the full create, edit, Git return, linked-worktree, restart, and cleanup test against the next release.

[geoff-ux]

@mislavivanda any thoughts on the above? Thanks!

[aprojic]

Hi @geoff-ux ,

Picking up item 3 from your list, the SSH host trust point. Items 1 and 2 are with engineering and being tracked separately.

Your assessment is correct, and this one is on us. There is no authoritative published fingerprint for ssh.app.daytona.io today, and DAYTONA_SSH_KNOWN_HOSTS is only as good as the value you put in it. Asking you to seed it from a first connection is trust on first use with extra steps, which is precisely what you are trying to eliminate.

On the SSHFP option: daytona.io is not currently DNSSEC signed. An SSHFP record over an unsigned zone would give you no verifiable trust path, so we are not going to publish one and present it as verification. If we sign the zone later, SSHFP becomes worth revisiting.

The correct fix is the one you are asking for. The gateway host key is operator-provisioned and stable per environment, not generated per boot, so a published fingerprint is a durable value rather than something that drifts under you.

The publication mechanism already exists on our side. The public /api/config endpoint models an sshGatewayPublicKey field, and it is unpopulated in production today, which is why you found the gateway public key absent from the live configuration. Populating it is a configuration action on us rather than a code change. We will populate that field and document the corresponding fingerprint in the security policy, so you can verify it out of band over TLS and then pin it via DAYTONA_SSH_KNOWN_HOSTS for strict noninteractive verification.

I am deliberately not pasting a fingerprint into this thread yet. Any value I could quote right now would be one I observed from a connection, which carries the same weakness you reported. It gets published once it has been confirmed against the provisioned key material.

Whether that fingerprint is additionally exposed through the SDK or consumed automatically by the plugin is a maintainer call rather than mine, so I will leave that part to the thread.

Ante
CISO, Daytona

[geoff-ux]

Thanks, Ante. This is exactly what we needed.

Populating sshGatewayPublicKey from the provisioned key material and documenting the fingerprint in the security policy gives us the authoritative, out-of-band trust path we were missing.

For our side, the plugin does not need to discover and trust the key automatically. A stable public key from /api/config, an independently documented fingerprint, and supported pinning through DAYTONA_SSH_KNOWN_HOSTS are enough, as long as we can verify that all three agree. Once those are live, we will run the strict noninteractive connection test and report back.

We will keep following items 1 and 2 with engineering. Thanks for taking ownership of this one.